Re: Rendezvous

[Jonathan Gapen]

On Mon, 9 Jun 2003 discuss-gnustep-request@gnu.org wrote:
> Date: Mon, 9 Jun 2003 01:56:57 -0500
> From: David Rogers <davidrogers23@earthlink.net>
> To: discuss-gnustep@gnu.org
> Subject: Rendezvous
>
> I'm new to the list.  I'd like to work on available tasks if possible.
> Does anyone know if there is a need/want for the NSNetService and
> NSNetServiceBrowser classes?  If not, what is on the top of the list
> right now?

     While I don't *need* it, I do *want* it.  :-)
     As others have pointed out, implementing these classes is going to
take quite a bit of extra infrastructure in the GNUstep system.
Rendezvous consists of three things:  1) automatic link-local IP
addressing, 2) link-local name resolution without a DNS server and 3)
service discovery without a directory server.  The first is beyond the
scope of GNUstep.  The second really ought to be a part of the host
system's DNS resolver, but GNUstep could support it in the NSHost class.
NSNetServices addresses the third point.
     Apple's source release is complete in the sense that you could
(barring the license issue) link it to each and every ZeroConf-enabled
GNUstep application and have it act as its own mDNS responder.  As their
documentation points out, that's rather inefficient.  It would be better
to have one mDNS responder per host computer that handles name and service
registration for all apps, and Apple's open source implementation doesn't
handle that duty.
     GNUstep, then, needs another daemon.  My vision is that the GNUstep
NSNetService class would use DNS UPDATE messages (RFC 2136) to register
with the mDNS daemon.  Why?  By their documentation, Apple intends to add
DNS UPDATE support to NSNetService to allow it to register services with
DNS servers.  This way the code to register with a DNS server and the code
to register in the .local. domain would be identical.  Also, as pointed
out, it's possible to register a service on Host A (a legacy system which
doesn't do mDNS) with an mDNS responder on Host B.  Instead of a
GNUstep-specific tool, the user may instead use standard tools that
support DNS UPDATE to register such services.
     Apps could each do their own mDNS resolution, but that bars use of a
shared cache in the daemon.  Instead, they might use GNUstep Distributed
Objects (over an NSMessagePort) to communicate with the daemon as it does
the resolution.
     Why an NSMessagePort?  Well, IMHO GNUstep should ditch gdomap in
favor ZeroConf.  The gdomap daemon does a highly specialized service
discovery on the local subnet using inefficient UDP polling.  ZeroConf
offers a more robust, general purpose service discovery that GDO can
easily leverage.  What's more, ZeroConf can (in the future) look up
services outside of the local subnet by talking to a DNS server.
     As you can see, there are some design decisions to make.  But in the
meantime, perhaps you can get the mDNS code from dotlocal.org under the
LGPL and build it in so that each app acts as its own mDNS responder?  It
would be inefficient, but inefficient is better than non-existant.

(P.S. Rendezvous is (tm) Apple, so I cite ZeroConf except where there's a
distinction between the two.)

-- 
Jonathan Gapen
 "To announce that there must be no criticism of the president, or that we
are to stand by the president right or wrong, is not only unpatriotic and
servile, but is morally treasonable to the American public." ---Theodore
Roosevelt