[avahi] Proposed BitTorrent Zeroconf protocol

[Marc Krochmal]

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

"_foobar._tcp,_subtype1,_subtype2,_subtype3"

Best Regards,

-Marc