On Tue, 20.09.05 11:27, Alexander Larsson ([EMAIL PROTECTED]) 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/ _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
