[gnome-network]Service Discovery for GNOME

[Ian McKellar <yakk yakk net>]

On Fri, 2003-09-12 at 02:47, Rodrigo Moya wrote:
> I've read that starting multiple responders was a problem in Mac OS. I
> may have misunderstood though, but if that's the case, I guess a
> system-wide daemon could work, couldn't it? It could have an easy way
> for user apps to announce the services they provide.

So I woke up this morning, read my mail and had a Vision. Its not much
of a vision but I'll share it anyway. 

Applications and users shouldn't have to know what sorts of remote
systems they'll be interacting with so the more we can abstract the
better. In the case of service advertisment and discovery we want to
support interoperability with at least Windows, MacOS, Linux and legacy
UNIX systems. This involves supporting:
  * multicast-dns & DNS-srv (Rendezvous)
  * smb browsing (for printers and smb file shares)

And possibly supporting:
  * UPnP (I don't know what actually uses but theres an sf.net project)
  * SLP (again, who uses / supports this?)
  * Traditional AppleShare service advertisment? Probably not a priority
  * NFS (IIRC you can send a broadcast query for NFS servers - Linux
servers never reply but most legacy UNIX servers do support this)
  * Novell browsing of some sort?

I'm not sure which of these protocols apart from mdns/dnssrv make sense
of service advertisment.

Additionally we could develop some kinds of peer-network service
discovery system. What I mean is provide hooks through
<insert-jabber-client-of-the-week> or even an irc client to
advertise/discover services. I'm really excited about this kind of idea
because Rendezvous is proving to scale pretty badly. It only lets you
discover services in your ip subnet - an arbitary technical restriction.
Often in a reasonably sized enterprise there will be several separate
subnets - for example one of my housemates can see different iTunes
shares from the different macs on his desk simply because of the IPs
that got allocated to each machine. Thats teh suck.

I think the best way to achieve this is through a per-session daemon
thats activated as required. This would be able to track what services
applications have requested to advertise and both monitor and query
advertisments from other hosts. We would have a CORBA interface along
the lines of the interface my GmDNSService and GmDNSServiceQuery classes
have. 

At the library level we could expose these interfaces, but I think the
more interesting API is what I've been hacking on but not committed to
gmdns yet. Application authors should never need to deal with IPs and
ports if they don't want to. They should be able to create a listen
socket and then ask for that service to be advertised by a given name
and service type. Also they should be able to query for particular
services and connect to instances of a service without worrying about
the details of it. 

One of the advantages of abstracting away these details is that the
responder daemon can be cleverer - as interfaces come up and down it can
re-advertise the services, with the address thats routable on that
interface rather than whatever IP the host originally thought it was.

Of course all this sounds like quite a bit of work, but a responder
daemon we can activate and talk CORBA at, either based off my
gmdns/mdnsd code or off another responder would have basically this
interface, just with limited interoperability and cool features. We can
fill in the rest as we go along.

Ian