Re: Moving to bonjour over howl

[Lennart Poettering <mztabzr 0pointer de>]

On Thu, 22.09.05 10:06, Alexander Larsson (alexl redhat com) 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/