[avahi] Resolve multiple IP4 Addresses

[Daniel Wynne]

On Thu, 2009-05-07 at 17:29 -0400, Mark Gollahon wrote:
> On Thu, 2009-05-07 at 19:57:37 +0200, Lennart Poettering wrote:
> 
> > On Thu, 07.05.09 13:09, Mark Gollahon (mgollahon at exacq.com) wrote:
> > 
> > > In my case, we are connecting to Axis cameras.  Some models of Axis
> > > cameras report their configured IP address first; others report their
> > > link-local address first.  Now, because of certain other design
> > > limitations and requirements that would take too much time to go into
> > > here, we have to store the camera's IP address when that camera is
> > > configured in our system.  So, if during our camera detection phase,
> > > Avahi hands back the link-local address, then we're totally sunk when
> > > the link-local address changes (which does at the most inopportune time
> > > - when the camera reboots and we're trying to reconnect).

> Avahi, as it is written, doesn't give me much choice in the matter!  In
> my scenario, I can rely on a configured IP address much more than on a
> link-local address or even a name resolve.  The link-local has a short
> lifespan (at most between reboots) and I cannot depend on "someone"
> entering name-to-ip maps into the hosts file.  Therefore, it makes sense
> to store and connect to the cameras using an IP address and not the
> name.
> 
> So, you call this an ugly hack.  I do not think so, but if it is a hack,
> it is a realistic one.
> 
> > IP addresses are not useful for identifying machines. IP adress can
> > change. IP addresses can be assigned to multiple machines. One
> > machine, even one network interface can have multiple IP addresses. IP
> > addresses are only unique and suitable for identification in a very
> > specific context, which is when you talk about network interfaces for
> > the use of routing on a specific network in a specific time frame.
> 
> I agree that this is a good argument for *not* using IP addresses to
> refer to devices on a network.  However, it is also a great argument
> *for* returning multiple addresses during an mDNS query.  If my device
> has multiple addresses (i.e. link-local and a configured one), why not
> return all to the querying process and give it the ability to *choose*
> which way to contact the device?  All of the name resolving mechanisms I
> know about have the ability to return multiple addresses to the program
> using it, all except Avahi.
> 
> > > Furthermore, trying to explain what that "169.x.x.x" address is or why a
> > > user doesn't see the address they configured into the camera to a user
> > > not versed in IP addressing is a complete non-starter.
> > 
> > Yes, IP addresses should generally not exposed to the user. That's why
> > host names have been invented.
> 
> Yes, I very much agree with this statement.  I would much rather deal
> with hostnames than IP addresses.  However, hostnames can change, too,
> so its not the panacea you are making it out to be.
> 
> > > Therefore, saying that scenarios where an mDNS recipient needs all
> > > addresses for a given DNS name is a misuse of mDNS really is
> > > disingenuous.  There really are times when we need all of the reported
> > > addresses we can get.
> > 
> > No. This is a hack. An ugly one. And a misuse of mDNS/DNS-SD.
> > 
> > This is precisely the reason why I chose not mimic the Bonjour API in
> > this aspect: people start to misuse the technology for things it
> > wasn't designed for.
> 
> I still do not understand where the mDNS spec says anything to the
> effect of "only return one address per host even if that host reports
> multiple addresses".  If it is there and I've missed it then it is my
> fault for not taking it into account.  If it is not, then it was nothing
> more than an artificially limiting implementation decision and I am not
> "misusing" mDNS/DNS-SD in any way.
> 
> > 
> > Lennart
> > 
> 
> Regards,
> Mark Gollahon
> 


Like Mr. Gollahon we also try to connect AXIS and related camera types.
The cameras answer with several IPs. The order of arrival is not
deterministic. Therefore WE have to decide which IP-Addresses we take
into account. A single network interface might have more than one IP,
which even might all be reachbale by the DNS-SD-client.

Disregarding any issue of "misuse" respectively "unspecified usage", the
DNS-SD interface should map the SPECS and not act as their guardian in
any way. Since DNS-SD allows the sending of several addresses, the
interface should deliver all of them to the user. In this issue I
totally agree with Mr. Gollahon.

Anyhow, I would be very thankful if Mr. Poettering sticks to giving this
great support with very short response time. This, I really appreciate
very much.

So back to my little problem ;-)

Is there a way to influence the timeouts of the ServiceResolver? We are
resolving many devices and before all can be resolved we receive
timeouts.
Is it a good practice to create a new ServiceResolver for every Service
found immediately?
Is there a maximum number of registered ServiceResolvers?

Thanx 

Daniel


> _______________________________________________
> avahi mailing list
> avahi at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/avahi