Archive for January, 2007

Google plane

Friday, January 26th, 2007

Google flew a plane over my house today – they’re taking hi-res photos for Google Maps.

Google plane flying over my house

Google Techtalks: Zeroconf

Thursday, January 25th, 2007

The first Google Techtalk made available on Google Video was a talk on ‘Zero Configuration networking’ by Stuart Cheshire in 2005 – I just got around to watching it. Here’s a summary of the most interesting bits (long and very nerdy):

Basics

Zeroconf was developed at Apple, and has been marketed as Rendezvous, and subsequently Bonjour. It’s designed to allow networked devices to be plugged in just like you can plug a lamp into the wall. It’s largely inspired by AppleTalk. Here’s how it works, roughly, for a system connected to a new network with no infrastructure (so no DHCP, etc):

  • Randomly choose a 169.254.* IP address
  • Do an ‘ARP who-has’ on that address, and take it if no-one responds

Now you have an IP address, but what about DNS names? First, we need a way to do DNS lookups (remember, we haven’t been told about any nameservers):

  • Standard DNS requests in Zeroconf are sent out as multicast
  • Zeroconf devices respond to multicast DNS lookups (the ‘mdnsresponder’ daemon you may have seen running on your machine): In the basic case, every device simply responds to lookups of its own hostname

So now we can pick a unique name:

  • Choose a name ending in ‘.local’
  • Perform a DNS lookup to see if this name exists, and consider it yours if no-one responds

Service Discovery (DNS-SD)

Service publishing/discovery (i.e. devices telling the network what then can do – “I’m a printer” etc) is implemented using obscure but apparently standard features of DNS, most interestingly SRV records. These are fascinating: They allow a given hostname to resolve to an IP address and a port, instead of just an IP address (for example: www.maebmij.org would point to 220.233.213.187:80). This is described as addressing an oversight in the original design of DNS – and he suggests that assuming a hard-coded port for each service is a hack resulting from it. (What are the implications here, outside of Zeroconf? You could replace webserver name-based virtualhosts with a range of ports, and corresponding DNS entries, for example. But it does increase reliance on DNS, since you could no longer (for example) ssh directly to an IP address.)

So, what steps are needed for service discovery for, say, finding IPP printers?

  • First, we issue a multicast DNS query asking who talks IPP:
    _ipp._tcp.local PTR ?

    – in other words, please give me all PTR records (i.e. other names, or perhaps ‘aliases’ if that’s the right term) for this name

  • All Zeroconf devices listen for such requests, and if they see one which describes them, they respond with a standard DNS response about themselves, again via multicast:
    _ipp._tcp.local PTR My Laserjet._ipp._tcp.local
    _ipp._tcp.local PTR photoprinter._ipp._tcp.local
    _ipp._tcp.local PTR Fax printer._ipp._tcp.local
    

    So we now have a list of the names of printers we can use.

  • Let’s use ‘photoprinter’: We need to know its IP address, and the port on which it’s listening, so we look these up using SRV records, described above, and ask for any metadata available as a TXT record while we’re at it. Here’s what a response might look like:
    photoprinter._ipp._tcp.local SRV 0 0 631 chewbacca.local
    photoprinter._ipp._tcp.local TXT pdl=application/postscript
    chewbacca.local A 192.168.1.60
    

    In other words, “photoprinter is a service on port 631 of chewbacca”. Note that the last line wasn’t explicitly requested (we didn’t know about the hostname ‘chewbacca’ until after receiving the first line) but the system helpfully gave it to us anyway – again, standard DNS.

Other neat things

  • To avoid ‘chattiness’ (which appletalk was accused of), responses and announcements are cached by all clients listening passively on the network – this is simple because the whole conversation occurs in multicast. One neat feature of this is that if a service goes offline, the first client trying to use it will fail to resolve its name into something useful (since it isn’t there to speak up). The client then tries to reconfirm the original PTR record. If this fails, all the other Zeroconf nodes notice and update their caches.
  • He mentions that if Zeroconf had been standardised ten years ago, it could have been where USB and Bluetooth are today – a universal interface with ‘plug it in and it works’ functionality, but with an opportunity for more nodes, longer cables, diverse physical media (wireless!), and lots of existing IP-based protocols (eg file exchange). Interesting to think about… could an ethernet controller be as cheap and small as a USB one though?

I am Jack’s wasted life

Tuesday, January 9th, 2007

Bus ad

This was on my bus this morning.

Interesting things to look at

Monday, January 8th, 2007
  • Nokia N800 linux tablet – not exactly sure what it can do, but it’s at least another attempt at improving the state of mobile computing.
  • In case you’d like to see this sort of thing: Internet millionaire Anshe Chung being attacked by giant flying penises during a CNET-organised press interview in Second Life. Make what you will of this; I’ll just comment that if Harry Potter-style magic really worked in the real world, we now have some idea of what it would be used for.
  • I watched Triumph of the Nerds recently – it was really good. One of the stories was about VisiCalc, the first spreadsheet (and the way the documentary tells it, the first killer app of any kind). The idea was never patented, and so once Lotus 123 came along, the inventors stopped getting any money, and are now conspicuously less wealthy than many of the other players in the early computer industry. I did some googling, and Dan Bricklin, the inventor of VisiCalc, has some interesting comments on software patents and VisiCalc on his blog.