Re: Service Discovery for GNOME

[Rodrigo Moya <rodrigo gnome-db org>]

On Fri, 2003-09-12 at 13:41 -0700, Ian McKellar wrote:
> 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.
> 
all this sounds perfect to me. So, if you agree, I'm going to start
writing the CORBA daemon.

cheers