Re: Moving to bonjour over howl

[Trent Lloyd <lathiat bur st>]

On Mon, Sep 19, 2005 at 09:24:52AM +0200, Alexander Larsson 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? 
> 
> 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.
> 
> > 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.
> 
> Doesn't avahi work like this? mDNS really was designed to have a
> system-wide daemon that does all the querying and caching, otherwise you
> can easily end up with way to much network traffic.

That is not correct, Avahi caches all authorative responses it has *seen*,
there is no way to guarantee the data in the cache is complete and can quite
easily not be, if you wanted to keep a fresh cache you would need a
program running in the background that was constantly querying the
service types we want, however, while this may seem like a good idea,
its a bad idea because this will cause the network to be hit with
queries with these all the time, while they will settle out to about 15
minutes after a while, it's not 'recommended' behavior and is
specifically condemened in the RFC.

In order to do that, what that code really needs to do at least is to
wait more than a second as a responder can be caused to delay a second
depending on the situation, in which case this would mean you may miss
some replies.

(And this whole conversation started from before lennart understood the
need for a 'sync' call)

Trent

> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc 
>                    alexl redhat com    alla lysator liu se 
> He's a deeply religious crooked dog-catcher on a search for his missing 
> sister. She's a chain-smoking nymphomaniac mercenary looking for love in all 
> the wrong places. They fight crime! 
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

-- 
Trent Lloyd <lathiat bur st>
Bur.st Networking Inc.