On Mon, 19.09.05 09:24, Alexander Larsson ([EMAIL PROTECTED]) 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?
The solution I still consider best is to have a background daemon that is forked off on demand, aggregates service information and is reused by all following operations, from all processes owned by the user. I don't know what gnome-vfs-daemon is exactly for but I thought it could be used for this, so that the need to fork off the daemon described above wouldn't be needed. The reason why I think that the "pseudo-synchronous" algorithm you implemented for your synchronous API (i.e. start browsing, wait some time, stop browsing and take the items retrieved in between as the list of currently available services) is bogus is the following: mDNS is in no way designed to be able to offer you "the" list of all RRs available at a time. Multiple traffic suppression algorithms in mDNS don't allow "one-shot" queries like "give all services available on the net right now". mDNS is designed for "long-lived" queries, and is only really reliable if queries are held at least for a second. However, this is a ridiculuous long time for synchronous operations as required for "gnomevfs-ls". Starting and stopping service browers everytime a synchronous operation is issued is a waste of resources, since it will cause at least one query to be sent on each invocation. In addition cache entries are not kept up-to-date unless at least one local client is subscribed to them. So your idea of relying on the internal cache of the mDNS responder is a nice hope, but actually unworldly. (The paragraph above is not the whole truth: actually mDNS *has* a mode for doing "one-shot" queries, called "legacy unicast", but using it is for simple things like gethostbyname() which only return a single response. It's a little perverse when you use it for real stuff like service browsing where multiple responses need to be aggregated, since it bypasses all caches and traffic suppression algorithms) > 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. Avahi has such a daemon too, but as described above it doesn't fit well for the things you want to use it for. Neither does HOWL itself. To put it short: your current code might work most of the time but it is against the design principles of mDNS, causes constant delays when using the synchronous gnome-vfs interface, and causes more traffic than needed. It's just not the mDNS way to do things. Yes, it's ugly to support synchronous operation on top of mDNS optimally. But that's the way it is. > > 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. Wrong. And wrong. And wrong. See above. Lennart -- Lennart Poettering; lennart [at] poettering [dot] de ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.de/lennart/ _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
