Re: Moving to bonjour over howl

[Lennart Poettering <mztabzr 0pointer de>]

On Mon, 19.09.05 09:24, Alexander Larsson (alexl redhat com) 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/