[avahi] Proposed BitTorrent Zeroconf protocol

[Lennart Poettering]

On Fri, 14.04.06 18:00, robin.perkins at internode.on.net (robin.perkins at internode.on.net) wrote:

> I just wrote this up to hopefully get some consistancy from
> which to work from for a bittorrent zeroconf 
> protocol. 
> 
> I would like to ask for some constuctive criticism and any
> commentry from people as to how well it is 
> likely to work.

Sorry for the delayed response!

A few comments:

First I must say, that I wonder if it is a good idea to generate
service types dynamically.

DNS-SD service types have a very strict form: "_foo._tcp" or
"_foo._udp" - with exactly two labels. DNS subtypes have the form
"_waldo._sub._foo._tcp". You should follow this rule for your service
types and subtypes.

Is the peer-id really necessary in the service name or type? Otherwise
i would drop it, naming the service after the local hostname, 
perhpas in a form like distcc does it: "distcc at foobar".

Service names should be human readable, and should not be used to
store binary information intended to be read by computers only.

Hence my suggestions:

The main service should bear a name like:

  bittorrent at foobar 

and a type of 
  
  _bittorrent._tcp

The subservice for the bt hash
32f17bbf96bdc77de85bb91ff8d56f124e817c0a should be:
  
  _32f17bbf96bdc77de85bb91ff8d56f124e817c0a._sub._bittorrent._tcp

You may include the peer-id in the TXT records if you think that makes
sense.

AFAIK Bonjour doesn't support adding more than a single subtype to a
service. Avahi doesn't have this limitation

Lennart

-- 
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/