[avahi] Fwd: On DBus

[Trent Lloyd]

Jean-Lou,

On 18/11/2009, at 1:17 AM, Jean-Lou Dupont wrote:

> Hi,
> 
>  I've been working on a pet-project ( a browser NPAPI plugin for
> exposing local HTTP services ) and I've been "slowed down" (to say the
> least) with the DBus interface.  It seems that in order to fully
> "resolve" a new service through DBus a 3 step process is required:
> 
> 1. Register a ServiceBrowser
> 2. Once an "ItemNew" signal is received, register a "ServiceResolver"
> in order to get the full details of the said service
> 3. Grab the service details on reception of the "Found" signal
> 
> This is painful.
> 
> Why can't Avahi just announce everything on DBus without having to ask
> for it??  It is not like we are talking about an unreasonable amount
> of traffic on DBus here.

This is because of thew ay the mDNS protocol works, and it is designed to reduce traffic.

As I explained on IRC last night, services do not immediately advertise all their details on the network, the only detail that is sent out is basically that a service called "X" with a type of "Y" exists.

To get further detail about the service, you must resolve it, this then makes an additional query and gets a response.  If we were to "automatically" do this on every service, the level of mDNS traffic would be insane, particularly on wireless networks and even more particularly if they were large.

Scaling issues have already been seen on conference wireless networks without this 'additional load'


Additionally.. due to the 'unreliable' nature of the protocol, such things are not guarnateeable, for example, if you just join a network, you will not immediately see announcements from people.. you have to request them.. so you can see even if everyone broadcasted all their records (which actually, they do at the start the first time a record exists) - every time someone joined the network - literally everyone would have to re-broadcast their entire catalogue of records.

Your application should try as hard as possible to not actually 'resolve' a service until it is required, this is not always possible since people often want extra data, but you can cheat and encode some flags into the service name, this is done by iTunes for example, password-protected shares have an _ prefixed to their name, so iTunes can show a padlock that its password protected before you click on it, without having to resolve the service. 

> 
> Am I missing something? Is there a better way of doing this?  ( FYI:
> an NPAPI plugin is best coded in C )

Why don't you use the avahi-client library?

It is much better than using DBUS directly...

Thanks,
Trent