On Thu, 22.09.05 10:06, Alexander Larsson ([EMAIL PROTECTED]) wrote: > > > The first time an application that uses gnome-vfs calls > > > gnome_vfs_open_directory (or gnome_vfs_async_load_directory) on > > > dns-sd://local/ (which will do a query for interesting fileshares using > > > mDNS) we: > > > 1) start long running queries in the background > > > 2) do a "synchronous" browse query > > > 3) Collect responses from both these callbacks and store in global state > > > > Why issue two queries if you aggregate the replies from both anyway? > > This is slightly bogus, in a non-optimal sense. The reason for this is > that the first query is "asynchronous", and will only report results if > the glib mainloop is run. Whereas the second one is actively iterated > under the 200 msecs.
So you let the first one starve for at least 200ms and even undefinitely if the application doesn't have a glib main loop? Hmm, that's not exactly what I call a "clean solution". > A nicer solution would do just one query and iterate it manually for 200 > msecs and then "convert" it to an asynchronous query, but that might be > tricky. In some other mail you stressed that gnome-vfs modules must not rely on the glib main loop. Now you say yourself that you use it for your "background query". > > > This is all done in each client, however, since the query will be > > > constantly active for as long as any process that has accessed > > > dns-sd://local/ once, howl should be able to cache all the results from > > > it. (If its smart enough to notice that a new query is identical to an > > > already running query and share them.) > > > > Avahi does detect this, too. But starting and stopping queries which > > are only referenced by a single program at a time is a waste of > > resources. > > I think this talk about resources is taking things a bit far. In > practice, for normal users, the only time this code is run is by > nautilus when the user visits the "Network" location (network:///, which > merges dns-sd://local/ if the gconf key /system/dns_sd/display_local is > set [on by default). Nautilus is generally a process that lives for as > long as the desktop session runs, so the query will always be running. > Very few other processes will normally read either network:// or > dns-sd://local/ directly. Valid point. But still not optimal. ;) > > > What part of this do you think is non-optimal, and how would you do it > > > instead? > > > > I still think the solution of forking off a background process that > > collects responses for all applications of a user is a better > > idea. Why? Because it makes sure that the query is kept as long as > > possible/useful to minimize traffic. In addition different > > programs can make use of the same aggregated data. (i.e. running > > gnomevfs-ls twice within a short interval would impose the aggregation > > delay for the first invocation only). Thirdly you need to wait at > > least a full second to get a reliable complete list of services on the > > LAN. However imposing a 1s delay everytime the user accesses a DNS-SD > > share is not very user friendly, so it's best to abstain from it as > > much as possible. > > In practice this forked off process is doing exactly the same work as > Nautilus does in the normal case. Relying on some special user app running for gnome-vfs to work is not the cleanest thing to do. Consider XFCE or some other DE adopting gnome-vfs. Unless they offer an always-running nautilus counterpart, the dns-sd module would be rather sluggish. > > (A quick side node: Avahi (SVN) fires a special signal "ALL_FOR_NOW" > > when it thinks that more responses are unlikely in the next > > while. Better use this as a replacement for an unconditional time > > based delay) > > Yeah, that sounds quite useful, and certainly better than hardcoding a > time. How do you detect when to fire it though? The algorithm is: For multicast DNS: if at least one other client is subscribed to this query and it was created more than a second ago we assume that the cached entries describe the complete current state of affairs. If the query is newer than a second we wait until the second elapsed. If no other client subscribed, we wait a second unconditionally. For unicast DNS: We assume that the cached information is complete, or if the cache is empty for this specific query we wait until the server responded. BTW: Current discussion with Marc Crochmal (the Apple guy behind mDNS/DNS-SD) on some unrelated issues yieled some results regarding the one second delay described above: the suppresion algorithms in mDNS will be modified in a way that allows us to decrease this value to something slightly higher than 500ms. 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
