[avahi] synchronous service discovery

[Mihai Ibanescu]

On Thu, May 04, 2006 at 11:13:59PM +0200, Lennart Poettering wrote:
> On Wed, 03.05.06 13:03, Mihai Ibanescu (misa+avahi at 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,

Hi Lennart,

Thanks for the detailed response. Since (for now) I am only using unicast DNS,
I'll probably just follow your advice. I didn't want to add the complexity of
(and dependency upon) an event loop when simple DNS lookups for PTR records
were enough.

As I found out, there are no good DNS libaries for python that are in
widespread use, as far as I can tell, and it's yet another dependency
- that's why I was looking for something within avahi.

Thanks again!
Misa