[avahi] Proposed BitTorrent Zeroconf protocol

Marc Krochmal marc at apple.com
Mon May 15 10:39:20 PDT 2006

On May 15, 2006, at 10:12 AM, Lennart Poettering wrote:

> 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.

I agree that the service type part should not be generated  
dynamically, however, the subtype part "_waldo", is free to be  
generated dynamically.

> 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.

It's true that most of the time service names are human readable, but  
it's totally possible that you could invent a protocol that doesn't  
require users to see the service name, and in that case, the service  
name could be anything you want.

> 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.

If it's possible to avoid using the TXT record, it would be better,  
but the TXT record could be used for this if necessary.

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

You can register many subtypes using Bonjour by passing them in as  
comma separated strings, like this...


Best Regards,


More information about the avahi mailing list