Ketan noted that it's very difficult to do range lookups or searches, since Chord is a distributed hash table and that's not what hash tables are good for. But as with databases, you can usually address this problem by adding a supplemental lookup table which lets you traverse the keys in some sorted order. Someone at Duke who was at TONIC today is actually working on this.

Amyn argued that having everything distributed everywhere doesn't make much sense, and that it is more productive to specifically choose nodes to provide your service based on the capabilities of that node. I don't completely disagree (ref. William Gibson's Idoru), but I do think there are real applications which would directly benefit from Chord. Namely, it would be great to have my home running off a DHT like Chord in conjunction with Zeroconf. That way, plugging in my new WD1200JB would add 120GB to every single system on my network, instead of just Binibik. I bought this drive because I needed more home directory space. But I am also running out of local disk space on my workstations. Adobe Photoshop could really benefit from something like this. The question of what happens when a disk goes down can already be addressed with RAID principles. A harder question is what happens when you take a machine somewhere else where it no longer has access to the "local network disk" (I will coin this term to refer to a local disk actually built on a network; i.e. not really local but also not remote). I think you would have to be able to specify specific blocks of data as guaranteed local, and then this would work.

In other news, the Vidcap machines were taken out of the DiRT lab to get partitioned for Windows 2000 and FreeBSD. I will be installing FreeBSD onto a second partition after those machines are returned to the lab.

Post a comment