[Olsr-dev] New plugin: DNSSD

[Dan Staples]

In my first email, I discussed what DNSSD does that P2PD does not do.
DNSSD simply builds on top of P2PD, so it keeps all the original
functionality. It seemed specific enough of a use that it might not be
appropriate to add to P2PD. But if it seems reasonable to simply add my
changes to the P2PD plugin, that is totally fine. It would probably make
a lot of sense to try to combine DNSSD / P2PD / mDNS since they all
share a lot of code and functionality. I simply wanted to present the
functionality that I had added and get some feedback.

On 02/15/2013 09:26 AM, Ferry Huberts wrote:
> so we now have 3 plugins that basically do the same???
>
>
>
> On 15/02/13 14:08, Dan Staples wrote:
>> Hi all, I have a new plugin for your consideration:
>>
>> The aim of the DNSSD (DNS Service Discovery) plugin is to control the
>> propagation of mDNS service advertisements on an OLSR mesh. The plugin
>> is based on the P2PD plugin code. Instead of forwarding mDNS traffic
>> onto the mesh with a fixed TTL value, as P2PD does, DNSSD allows each
>> local service to define it's own TTL value. For example, a service that
>> has a TTL value of 3 will only be advertised a maximum of 3 hops away.
>> This can be useful for services and applications that either want to
>> remain local in scope (like a community bulletin board) or whose service
>> quality degrades after so many hops (like streaming voice or media).
>>
>> The plugin works as follows:
>> * DNSSD searches through Avahi service files in a directory specified by
>> the "ServiceFileDir" config option.
>> * Any service files in the directory containing a TTL txt-record field
>> and a domain field matching the "Domain" config option (e.g.
>> 'mesh.local') are added to a list of local services.
>> * Just like the P2PD plugin, DNSSD listens on non-OLSR interfaces and
>> forwards mDNS packets to the mesh, but with the following differences:
>>      -- Any non-query Resource Records that describe any service in the
>> list of local services are stripped out, and the remaining packet is
>> forwarded with the default TTL value.
>>      -- Resource records that were stripped out are sorted into bins
>> according to the custom TTL values of the local services they describe.
>>      -- Each bin of RRs is then put into a new mDNS packet, given a
>> custom TTL value in the OLSR header, and then forwarded to the mesh.
>>
>> Let me know if you need any clarifications. I tested it on a local
>> Commotion mesh and it seems to work fine. The code can be found here:
>> https://github.com/danstaples/olsrd-dnssd. I'll be doing more testing
>> soon on a larger mesh.
>>
>> cheers,
>> Dan Staples
>>
>

-- 
Dan Staples

Open Technology Institute
https://commotionwireless.net