that would not work, because of how dns(1) presents its interface. if the file server presented a directory of files then you can merge them.
however dns has a single file that you open, write a request to, and then later read a reply from. in this later form you merge the directories you just have two request files, rather than one request file which offers the service of moth files. I am not sure I have explained this very well, I hope you understand. -Steve > On 2 Jan 2016, at 05:17, Marc Boschma <[email protected]> wrote: > > Still getting my head around Plan9 but wouldn’t mounting the unicast and > multicast DNS file servers over the top of each other work? (I assume the > order of the mount (bind) would lead to resolution order… but maybe no > unified responses. > > Marc > >> On 2 Jan 2016, at 2:42 pm, erik quanstrom <[email protected]> wrote: >> >> On Fri Jan 1 19:32:25 PST 2016, [email protected] wrote: >>> >>>> On 2 Jan 2016, at 7:05 am, Steve Simon <[email protected]> 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 >
