Storage node discovery via avahi

[T_X]

In our use-case we are running tahoe-lafs within a public, decentral mesh network. Both OLSR with the help of a plugin and B.A.T.M.A.N.-Advanced support mDNS service discovery. It would be great if storage nodes could announce themselves not only via an introducer node but with the help of avahi. The advantage would be that storage nodes do not have to agree on a certain introducer node, reducing the program external, manual management overhead. E.g. I don't have to maintain a central wiki page for people wanting to contribute storage, people don't need an internet connection and knowledge about a wiki page to reach and configure their tahoe-lafs nodes correctly. In fact, in a mesh network the introducer node might sometimes not be available to all other nodes within the mesh network due to its dynamic nature, making it difficult to agree on one (or more, see #68) introducer node. And compared to the single introducer concept it improves the reliability of a storage grid in general.

Also for for instance company networks this could be beneficial where the hosts are already connected via a VPN: Here again it is very easy for an administrator then to add additional storage capacity to the private storage grid.

So a storage node could announce for instance:

Name: Tahoe-LAFS Storage Node

Type: _tahoe-lafs-storage._tcp

Port: as configured in tahoe.cfg (default: 8098)

​http://www.dns-sd.org/ServiceTypes.html

Additionally an introducer node should add locally discovered storage nodes to their reports, too. This allows other tahoe-lafs nodes which are not in reach for the mDNS service discovery to still find and connect to each other (for instance in our use-case multiple metropolitan mesh networks connected via bgp etc.).

​http://avahi.org/

​http://avahi.org/wiki/PythonPublishExample

​http://avahi.org/wiki/PythonBrowseExample

(A short note about this topic was also dropped here before ​http://tahoe-lafs.org/trac/tahoe-lafs/ticket/68#comment:3.)

[alexs]

I've got some of the tedious technical issues sorted involved DBUS and twisted event loops but could use some input on the protocol.

My current thinking is that it might be best to add a "please check mDNS-SD for this host" hint to the FURL. It would be pretty quick and simple to poll Avahi's database over dbus for services with a matching TubID in the name.

[alexs]

Initial patch of this is up in my tree on github.

​https://github.com/public/foolscap -- new "zeroconf" location hint in FURLs ​https://github.com/public/tahoe-lafs -- config support to enable publication via foolscape

[zooko]

Replying to alexs:

Initial patch of this is up in my tree on github.

​https://github.com/public/foolscap -- new "zeroconf" location hint in FURLs ​https://github.com/public/tahoe-lafs -- config support to enable publication via foolscape

alexs: are the patches ready for review? "Ready for review" here means: (a) you think they are ready to be committed to trunk, and (b) they have complete unit tests.

[zooko]

P.S. If they are ready for review, please add the review-needed keyword to the Keywords field.