On Mon, Sep 19, 2005 at 09:24:52AM +0200, Alexander Larsson wrote: > On Fri, 2005-09-16 at 23:33 +0800, Davyd Madeley wrote: > > On Fri, 2005-09-16 at 17:17 +0200, Alexander Larsson wrote: > > > > > I'm not saying Avahi needs a mainloop. However, GServiceBrowser clearly > > > needs one. Anyway, I was just explaining why the gnome-vfs dns-sd code > > > looks like it does. It seemed like David just looked at it and said > > > "ewww, this is ugly, I'll do my own thing instead" without an > > > understanding of why it looks like it does. > > > > It is currently designed to handle a more generic case. > > > > I am not sure why the DNS-SD code has to necessarily be able to handle > > synchronous and asynchronous calls. Shouldn't gnome-vfs-daemon simply be > > tracking devices on the network which are then offered in some logic way > > back to the gnome-vfs API? > > How do you implement the commandline call "gnomevfs-ls network:///" > which does a synchronous gnome-vfs readdir call, that will return > results from a dns-sd call, with an asynchronous dns-sd call? > > Also, I'm not sure why you brought up the vfs daemon here. Howl already > has a daemon, and that daemon is doing all mDNS work, including caching > all mDNS state from things that has been seen on the network. > > > It seemed to me at the moment that Howl gets stopped and started a lot, > > which would either cause sporadic blasts of network traffic or cause > > events to be missed. I'm not sure which. Please correct me if I've > > understood it entirely wrong. > > Started and stopped? The Howl daemon runs all the time, and it caches > the current state of all mDNS records in the local network (as long as > their TTL specifies). Then all howl clients (such as e.g. gnome-vfs) ask > the daemon for data, and most of the time the howl daemon can > immediately reply. There are no events missed, and there is no > unnecessary traffic. > > Doesn't avahi work like this? mDNS really was designed to have a > system-wide daemon that does all the querying and caching, otherwise you > can easily end up with way to much network traffic.
That is not correct, Avahi caches all authorative responses it has *seen*, there is no way to guarantee the data in the cache is complete and can quite easily not be, if you wanted to keep a fresh cache you would need a program running in the background that was constantly querying the service types we want, however, while this may seem like a good idea, its a bad idea because this will cause the network to be hit with queries with these all the time, while they will settle out to about 15 minutes after a while, it's not 'recommended' behavior and is specifically condemened in the RFC. In order to do that, what that code really needs to do at least is to wait more than a second as a responder can be caused to delay a second depending on the situation, in which case this would mean you may miss some replies. (And this whole conversation started from before lennart understood the need for a 'sync' call) Trent > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > [EMAIL PROTECTED] [EMAIL PROTECTED] > He's a deeply religious crooked dog-catcher on a search for his missing > sister. She's a chain-smoking nymphomaniac mercenary looking for love in all > the wrong places. They fight crime! > > _______________________________________________ > desktop-devel-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Trent Lloyd <[EMAIL PROTECTED]> Bur.st Networking Inc. _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
