Re: Moving to bonjour over howl

[Lennart Poettering <mztabzr 0pointer de>]

On Tue, 20.09.05 11:27, Alexander Larsson (alexl redhat com) wrote:

> I think you're sort of misguided at how this currently works, and not
> very good at describing exactly how your optimal solution works. Let me
> describe in exact detail how this actually works with the current
> gnome-vfs + howl solution:
> 
> The howl daemon is always running, and all queries clients done happen
> through it.
> 
> 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?

> 4) After 200 msecs, cancel the query in 2)
> 5) return a list of results based on the global state
> 
> On any subsequent call to gnome_vfs_open_directory() we immediately
> return the list from the global state, which is constantly kept
> up-to-date by the query started in 1).

Oh, OK. I must admit that you right, I apperently didn't understand
your code. I still wonder why you issue two queries simultaneosuly for
the same thing?

How is the background query kept alive? In a thread? In its own
process? 

> If the application adds a monitor using gnome_vfs_monitor_add() on
> dns-sd://local/ the monitor will be called with ADDS and DELETES as we
> get responses to query 1. All "normal" gnome-vfs UI apps like Nautilus
> and the file selector do this.
> 
> 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. 

> This gives us:
> * Nice "normal" async mDNS dns-sd for normal apps, with only a 200 msec
>   delay the first time an app reads dns-sd://local/
> * A mostly working sync-only readdir call for odd things like
>   gnomevfs-ls.
> * Basically no unnecessary queries sent on the network. 
>   (Assuming howl is smart, but even if its not, at most one query per
>    gnome-vfs app that reads dns-sd://local/, which in practice is only
>    done by Nautilus.)

> 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.

(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)

Lennart

-- 
Lennart Poettering; lennart [at] poettering [dot] de
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.de/lennart/