9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] bonjour mDNS?
@ 2016-01-01 20:05 Steve Simon
  2016-01-02  3:30 ` Marc Boschma
  0 siblings, 1 reply; 6+ messages in thread
From: Steve Simon @ 2016-01-01 20:05 UTC (permalink / raw)
  To: 9fans


anyone done any work to implement mDNS / bonjour on 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.

-Steve





^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [9fans] bonjour mDNS?
  2016-01-01 20:05 [9fans] bonjour mDNS? Steve Simon
@ 2016-01-02  3:30 ` Marc Boschma
  2016-01-02  3:42   ` erik quanstrom
  0 siblings, 1 reply; 6+ messages in thread
From: Marc Boschma @ 2016-01-02  3:30 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs


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

> -Steve
> 

Marc


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [9fans] bonjour mDNS?
  2016-01-02  3:30 ` Marc Boschma
@ 2016-01-02  3:42   ` erik quanstrom
  2016-01-02  5:17     ` Marc Boschma
  0 siblings, 1 reply; 6+ messages in thread
From: erik quanstrom @ 2016-01-02  3:42 UTC (permalink / raw)
  To: marc, 9fans

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [9fans] bonjour mDNS?
  2016-01-02  3:42   ` erik quanstrom
@ 2016-01-02  5:17     ` Marc Boschma
  2016-01-02  9:21       ` Steve Simon
  0 siblings, 1 reply; 6+ messages in thread
From: Marc Boschma @ 2016-01-02  5:17 UTC (permalink / raw)
  To: erik quanstrom; +Cc: 9fans

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




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [9fans] bonjour mDNS?
  2016-01-02  5:17     ` Marc Boschma
@ 2016-01-02  9:21       ` Steve Simon
  2016-01-02  9:59         ` Marc Boschma
  0 siblings, 1 reply; 6+ messages in thread
From: Steve Simon @ 2016-01-02  9:21 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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 <marc@boschma.cx> 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 <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
> 



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [9fans] bonjour mDNS?
  2016-01-02  9:21       ` Steve Simon
@ 2016-01-02  9:59         ` Marc Boschma
  0 siblings, 0 replies; 6+ messages in thread
From: Marc Boschma @ 2016-01-02  9:59 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

That makes perfect sense…

So dns(1) should probably be patched then…?


Marc

> On 2 Jan 2016, at 8:21 pm, Steve Simon <steve@quintile.net> wrote:
> 
> 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
> 




^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2016-01-02  9:59 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-01 20:05 [9fans] bonjour mDNS? Steve Simon
2016-01-02  3:30 ` Marc Boschma
2016-01-02  3:42   ` erik quanstrom
2016-01-02  5:17     ` Marc Boschma
2016-01-02  9:21       ` Steve Simon
2016-01-02  9:59         ` Marc Boschma

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).