[9fans] mDNS

[9fans] mDNS

[Steve Simon]

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]


mmmm, 

I am confused, are you talking of replacing the interface to dns(1)?

I had no real plan, maybe to just make mDNS accumulate broadcast and
multicast mDNS messages into a virtual file in /lib/ndb format.

more importantly I really need a publish system, which would be just based off
/lib/ndb/local, just a static spec.

my target is porting shairport, and maybe Dnla at a later date.

-Steve


> On 2 Jan 2016, at 03:42, erik quanstrom <quanstro@quanstro.net> wrote:
> 
>> On Fri Jan  1 19:32:25 PST 2016, marc@boschma.cx wrote:
>> 
>>> On 2 Jan 2016, at 7:05 am, Steve Simon <steve@quintile.net> wrote:
>>> anyone done any work to implement mDNS / bonjour on plan9?
>> 
>> No, but I have an interest; just starting out with Plan9 :)
>> 
>>> my rough plan is to write a file server which generates /lib/ndb/mdns
>>> which can be included into your /lib/ndb/local.
>>> 
>>> I fear the biggest hassle is the clash of UDP port use may mean
>>> mDNS must become part of dns(1) rather than a separate file server.
>> 
>> Shouldn’t dns(1) only bind to unicast UDP port and thus mDNS could bind to the multicast UDP port?
>> 
>> Are you only considering resolution or also publishing services?
> 
> it would make sense to me to make a dnsudp request file server that manages requests, and
> fork (ha!) that task off to it.  this file server would not care if it's querying normal dns,
> or mdns.
> 
> - erik

[-- Attachment #2: Type: text/html, Size: 5475 bytes --]

Re: [9fans] mDNS

[erik quanstrom]

On Sat Jan  2 01:31:36 PST 2016, steve@quintile.net wrote:

>
> mmmm,
>
> I am confused, are you talking of replacing the interface to dns(1)?
>
> I had no real plan, maybe to just make mDNS accumulate broadcast and
> multicast mDNS messages into a virtual file in /lib/ndb format.
>
> more importantly I really need a publish system, which would be just based off
> /lib/ndb/local, just a static spec.
>
> my target is porting shairport, and maybe Dnla at a later date.

that wasn't what i had in mind at all.  dns(1) does a whole bunch of things,
including.
- answering queries via /net/dns
- answering queries via udp, and tcp,
- maintence of database ndb files
- resursive resolution via udp or tcp
- caching of results

currently these functions are all in ndb/dns, and there isn't even threading.
that seems like a hard structure to maintain.

- erik