On Tue, 28.06.05 15:02, Joshua Blanton (jb135500@...) wrote:
> Sorry for the lack of proper threading - I'm not actually subscribed
> to this list... However, there was a discussion in #gaim after you
> left that I was asked to summarize, so here goes:
>
> I'm not sure that I buy the two listed "problems" with running
> multiple mDNS stacks on a single host... The first argument (that
> known answer suppression would keep a remote host from responding) is
> only true if the request contains the remote host's record; in the
> case where a second stack is present, the remote host's record will
> not be present in the request, which should cause the remote host to
> respond. If the remote host has already responded to the question
> recently enough, it may not respond - but this is unrelated to the
> known answer suppression scheme, and this could be triggered by
> multiple hosts running the same query on the same subnet.
This incompatibility makes mDNS unreliable when two or more stacks run
on the same host. I did not say that mDNS fails to work
completely. Look a this situation: two stacks run on the same
machine. The first stacks runs a so called "continuous query" for a
certain type of RRs (i.e. one gaim instance browses for
_presence._tcp). Some time later (perhaps a few minutes) the second
stack starts a query for the same type of records. (i.e. another user
starteted a gaim instance). With a high probability the second stack
will not get the responses the first stack got a few seconds earlier
because the first stack already send a second query (since it's doing
a "continuous query") which contained suppresion records which tell
all potential responders "this host already knows about these
records". The problem is, that there is no way to say "this *stack*
already knows about these records". Only "this *host* already knows ..."
is possible.
Or another example: the user starts a tool which enumerates all
available services of any type on the local network
(e.g. avahi-discover from the avahi distribution, see a screenshot:
http://freedesktop.org/~lennart/discovery.jpeg) This tool will start
issuing continuous queries for all available types of records at the
same time. Which means: shortly after starting this disocvery tool the
stack it is running on knows about nearly all RRs on the entire
network. i.e. that stack will suppress almost all records from now
on. Yes, other stacks on the same host do have a chance to issue there
queries in a period of time where the suppresion is no longer
active. But if avahi-discover and that other tool (perhaps) are
started at the same time (i.e. because the user just logged in and a
session manager of some kind started them simultaneously), it is
almost certain that one of the stacks will never get knowledge of a
great part of the RRs.
> The second argument was about binding multiple clients to the same TCP
> session, for directed responses... If the mDNS clients don't request
> directed responses they will never receive them, and it won't matter.
> If they do request them, then they deserve the potential loss of
> reliability associated with that setup.
Yes, but at least the Apple implementation of Bonjour *does* use the
unicast reply bit. Which means gaim would conflict with it. If you
abstain from using the unicast reply bit, all stacks on the local
machine have to abstain from it, not just gaim.
If you remove certain features from the mDNS spec you get a thing that's
just "mostly interoperable with mDNS, but not mDNS". I doubt that this
a good idea. The mechanisms described in the mDNS RFC mostly do make
some sense, so there's no point in dropping them at free will.
> I see many problems with running a separate mDNS client, in terms of
> correctness (it seems to me that one correct implementation running as
> a daemon would be *far* superior than everyone hacking up his/her own
> partially correct daemon that Works For Them), but technically I don't
> see any major issues with running two clients on the same machine.
Oh, there are!
In addition, running multiple stacks on the same host is a waste of
resource both in terms of network traffic and on CPU/ram. The
advantage of implementing the sophisticated cacheing the mDNS spec
dictates is almost lost if you run multiple caches on the same host.
Also, network traffic validation is a security sensitive area. Most
mDNS responders run as their own users or even chrooted. You lose that
extra security if build your own mDNS stack in-process.
I don't want to force the gaim people to implement it the way I would
like it. I just want to warn you in advance that this all has some
subtleties you don't see at the first glance.
If the gaim people still insists on running their own mDNS stack
directly integrated into gaim, please consider making use of
libavahi-core, a shared library that implements an mDNS stack. Just
for the sake of code reusing. It's already quite stable and the basis
for the avahi daemon. It's built aroung the glib main loop so it
should be very easy to integrate this with gaim. See
http://0pointer.de/public/avahi-doxygen/core_8h.html for an
(incomplete) overview of the API. The DBUS based client API for the
avahi-daemon will probably look similar.
Thank you,
Lennart
--
name { Lennart Poettering } loc { Hamburg - Germany }
mail { mzft (at) 0pointer (dot) de } gpg { 1A015CC4 }
www { http://0pointer.de/lennart/ } icq# { 11060553 }
|
