On Wed, 03.05.06 13:03, Mihai Ibanescu (misa+avahi redhat.com) wrote:
Hi!
> I am trying to use zeroconf with unicast dns (using SRV
and PTR records for
> describing the services that are available in the
network).
>
> Although I think I can see how I can use the python
bindings to do the service
> discovery asynchronously, I don't think I was able to
find anything for
> synchronous calls. I am looking for the equivalent of
doing a PTR lookup (both
> for browsing the domain and for browsing instances for
each service type).
>
> Is there such a thing in the API?
Nope. Avahi doesn't provide a synchronous DBUS interface
for service
browsing. Only resolving can be done synchronously. The
reason is that
mDNS/DNS-SD is a "living" system where services
appear and disappear
every now and then. Avahi doesn't maintain a list of all
currently
available services all the time. Instead, only if a local
client
browses for something a list is assembled from the responses
recieved
from the LAN. However, we never know when this list is
complete. (Just
think of a crowd of a few thousands of people. Tell them to
shout
their names, all at the same time. You'll see that you can
never make
sure that everyone of them has really followed your order or
even that
everyone understood your order in the first place)
Hence there is no clean way to implement a synchronous
browsing API:
we just never know when the right time to return has come.
However, the asynchronous browser API has a facility that
can emulate
the behaviour for you: an AVAHI_BROWSER_ALL_FOR_NOW event is
emitted
if Avahi thinks that it is unlikely that more responses will
turn up
in the the near future. (This is used by "avahi-browse
-t")
AVAHI_BROWSER_ALL_FOR_NOW is generated like this:
1. On mDNS, if there are already local clients querying
the same
record type, return it immediately if the first of the
clients
began to query it more than a second ago. If they began
less than
a second ago, wait until the second elapsed.
2. On mDNS, if there are no other local clients querying
the same
record type, just wait a second
3. On unicast DNS, just wait until the server responded,
since we
don't need to aggregate multiple responses in this
case.
Keep in mind that this event is unreliable. It might
definietly happen
that another service is found just msecs after this event
was
generated.
I hope this helps,
Lennart
--
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lenn
art/
_______________________________________________
avahi mailing list
avahilists.freedesktop.org
h
ttp://lists.freedesktop.org/mailman/listinfo/avahi
|