n2n revisited (by alaric)

I have spoken before about n2n, the peer-to-peer VPN tool that makes it easy to create efficient virtual networks.

Normal VPN products are really more of a "virtual private cable" than a "virtual private network" - they just establish a point-to-point link over the Internet, requiring a login to set it up and encrypting the traffic. This means you can have a virtual connection to a real private network somewhere; and if a few people connect into that network via VPN links, then there really is a virtual private network between you all, but all going through a central point where all your links meet.

While with n2n, everyone connects to a shared "supernode" that keeps a list of who is connected to the VPN, and from where; then when you want to connect to somebody else, you use the list from the supernode to establish a direct encrypted connection between yourself and them, rather than going through any central point. So it's an actual virtual network out of the box. You can even have more than one supernode running, so that any one can fail; all the supernode does is to provide the directory service.

Also, you don't need to maintain a database of user logins; a supernode can carry any number of virtual networks. When you connect to the supernode, you just tell it the name of the community you want to join, and it will share your connection details with anybody else in the same community - you can make communities up on the fly rather than needing to maintain a central list. Access control is handled by the simple fact that you need to know the correct encryption key for the community you want to join, or your messages will be received garbled by everyone else, and ignored.

Anyway, for a long time, I wanted to get into n2n, but I couldn't as it didn't compile out of the box on NetBSD; but a desire for a better VPN solution at work has led to me getting it working. It wasn't that much work, in the end, as the existing FreeBSD support already had a BSD approach to things.

n2n is distributed via Subversion, so they don't have version tarballs - this is a problem for my NetBSD port. So I decided to mirror it into git with git svn, then forked it as "Kitten n2n", made my NetBSD port, tagged a release, pushed it to github, uploaded a tarball from that tag, and then made a NetBSD package of net/kitten-n2n.

I'll tinker with it for a few more days, then I'll submit it to the NetBSD folks for consideration.

I'll keep pulling in from the official n2n Subversion repo, to pull down patches, and I'll see if they'd like my patches pushed up - as well as NetBSD support, there's a few things I'd like to fix as well (I've spotted passing an integer through a void* by casting, which is slightly dodgy practice and produces warnings on my 64-bit machine, but is easily fixed by passing a pointer to a heap-allocated copy of the integer!)

Designing a global knowledge base (by alaric)

Continuing from my previous posts on HYDROGEN and IRON, I suppose the next thing I can talk about is CARBON.

One thing that users expect out of a system is some form of navigational structure. All but the simplest embedded computer systems have some kind of menu structure; while workstations often have several somewhat confusingly overlaid structures (menus in applications, a "My Documents" hierarchy full of personal stuff, a "Start Menu" or "Applications Folder" full of system-wide resources, and a "My Computer" hierarchy with things like removable drives and their contents, printers, access to the internals of the system, mounted network drives, and the like; then, via a Web browser, a hierarchy of bookmarks and then whatever navigational structures different Web sites out in the world present to you.

So, I clearly needed some concept of "large-scale organisation of resources" in ARGON. After much deliberation, I came up with CARBON. But, as usual, I like to kill several birds with one stone.

Read more »

Generic Functions (by alaric)

When most people think of object-oriented programming, they think of the interpretation of it that originated in Simula, that has since bubbled into Java, C++, and so on. Or maybe the prototype-based variant found in Self or JavaScript.

Read more »

Designing a general data model (by alaric)

All that talking about HYDROGEN was such fun, I was sad it was over.

So what could I explain about ARGON next? My design for CHROME is currently just a list of features and a plan for how to put them together, with no details whatsoever; TUNGSTEN is still in flux because I have research to do in the field of replicated storage, LITHIUM depends on TUNGSTEN, MERCURY depends on CARBON and LITHIUM, and so on.

So, I guess I'll have to talk about IRON, which is a data model.

Read more »

HYDROGEN: Conclusion (by alaric)

As promised, here is the sixth and final part of my series on HYDROGEN, where I draw some conclusions and discuss the road ahead.

Read more »