Adventures in ad-hoc networking
Warning! Technical content ahead!
Increo’s office network is small and simple. All of our servers live at professionally-managed data centers, and our office has nothing more than a consumer-level wireless router on a shared Internet connection from Palo Alto’s Fiber Internet Center. Everything is wireless. It’s great, inasmuch as our total network equipment cost was in the two digits and adding a new computer takes no time at all. There’s no DNS server and no IP assignment; everything “just works”.
It becomes interesting, of course, when computers in the office need to connect to each other. For this, we turn to Zeroconf and multicast DNS, implemented as Bonjour on the Mac, Bonjour for Windows on Windows, and the team of Avahi and nss-mdns on Linux.
Now we can use computer names to connect to each other’s machines, no setup required. It’s really slick, and it has worked really well for us. At least, it works seamlessly up and to a point.
The new Backboard viewer brings a whole bunch of enhancements to the table, one of which is instantaneous updates whenever somebody else leaves feedback or the owner adds a new version of the document. Your feedback becomes a real-time conversation instead of a bulletin board, which makes collaboration that much easier.
As you might expect, this feature uses the Comet pattern, keeping a connection open to the server for live updates. We’re running a separate server for these messages, as infrequently rendering a large, complex page and then closing the connection is a very different task than frequently sending small, simple updates and keeping the connection open. Since JavaScript on the latter server has to update a page served from the former, it’s considered Cross-Site Scripting, but since the messaging server is on a subdomain of getbackboard.com, it still works in a secure manner.
Of course, since the office where we develop this has no explicit DNS, the web server (usually the local machine, say “mymachine.local”) and the messaging server (“theserver.local”) don’t share a domain. Unlike on the web, where you can set the document.domain variable to your second-level domain name, you can’t just allow cross-site scripting within “.local”.
The solution is a bit of a hack: use your operating system’s hostname resolution to simulate regular DNS names. In my case, I added “mymachine.local.getbackboard.com” and “messaging.mymachine.local.getbackboard.com” to /etc/hosts, pointing to 127.0.0.1 and the link-local IP address of the local messaging server, respectively.
This begins to undermine the ad hoc nature of our network, though: since the hosts file only does simple translation of hostnames to IP addresses and doesn’t mimic the “CNAME” functionality of DNS, I now have a totally arbitrary, non-guaranteed IP address hard-coded on my machine, so it’s not a complete solution. But it’s a start, and it works for now; it’s certainly easier than fully managing our office network.