[avahi] how to determine if an AvahiAddress is the local machine's?

[Charles Schmidt]

On Fri, 2005-09-09 at 23:10 +0200, Lennart Poettering wrote:
> On Fri, 09.09.05 03:16, Charles Schmidt (cschmidt2 at emich.edu) wrote:
> 
> > -
> > 
> > As far as I can tell, there is no API for determining if a given
> > AvahiAddress refers to an IP that the local machine has.  Something like
> > avahi_address_is_localhost() or avahi_address_is_this_host() would be
> > quite nice for filtering through resolve responses to get only those
> > that aren't services from the local machine
> > 
> > Right now, I'm using:
> > 
> > static gboolean
> > is_local_address (const gchar *address)
> > {
> > /* address here was got with avahi_address_snprint() */
> > 	static struct hostent *he = NULL;
> > 	struct in_addr addr;
> > 	gint i;
> > 	gint ret;
> > 	gchar hostname[255 + 6];
> > 	
> > 	ret = gethostname (hostname, 255);
> > 	if (ret) {
> > 		return FALSE;
> > 	}
> > 
> > 	strncat (hostname, ".local", 6);
> > 	he = gethostbyname (hostname);
> > 
> > 	if (he == NULL) {
> > 		return FALSE;
> > 	}
> > 
> > 	for (i = 0; he->h_addr_list[i]; i++) {
> > 		memcpy (&addr, he->h_addr_list[0], sizeof (struct in_addr));
> > 
> > 		if (strcmp (inet_ntoa (addr), address) == 0) {
> > 			return TRUE;
> > 		}
> > 	}
> > 
> > 	return FALSE;
> > }
> > 
> > But I'm not sure that this is a) the best way or b) something that will
> > work in all situations (multiple interfaces).  Can anyone suggest a
> > better way to do this?
> 
> Hmmh, nowadays the local hostname returned gethostname() needs not to
> be available via gethostbyname() at all. Some people consider
> depending on that behaviour a bug. Especially since not everybody has
> nss-mdns running, i.e. on a host foo the name foo.local may not be
> resolvable. (another issue: some people set the kernel hostname to
> the FQDN, which breaks you code. You should truncate the kernel hostname
> at the first dot.)
> 
> I acknowledge that some way to determine whether a service is on the
> local machine is useful. Unfortunately these things are not that
> easy. I had a short discussion with Marc Krochmal on a related issue:
> I'd like to see a way to detect if two services with the same name on
> different interfaces are actually identical. The idea is to add a
> random cookie to each service TXT RR implicitly. If the cookie
> matches services are identical. This could be used for your stuff,
> since the cookie is the same for all services on the local machine.
> 
> The downside of this cookie thing is that it requires the consumer to
> resolve a service before one can detect if it is identical to
> another. Which is contrary to what mDNS/DNS-SD was designed for. 
> 
> Same issue with your "is address local" suggestion: you need to
> resolve a service before you can make this check.
> 
> However, due to some reasons we can optimize for this stuff a little
> and so I decided to add support for this cookie thingy soon. 
> 
> The client api of avahi will gain a new function
> avahi_client_get_local_service_cookie() (wrapping the DBUS method
> "GetLocalServiceCookie()" which returns the cookie used by the local
> daemon for you. You have to parse incoming TXT records yourself the
> special field "avahi.cookie" for the cookie.
> 
> Second I will add a function avahi_client_is_service_local() (wrapping
> DBUS "IsServiceLocal()") which can be used to check if a specific tuple
> (interface,protocol,name,type,domain) refers to a locally defined
> service. This is probably what you want to use, since it doesn't
> require resolving of a service to check if it is local.
> 
> Third I will add a new DBUS API function "IsAddressLocal()" for
> you. However, we will not add a wrapper in avahi-client for that. If
> you use avahi-client you can use netlink or SIOCGIFCONF directly. Or
> use the cookie stuff/avahi_client_is_service_local(). The reason why I
> add it as DBUS method is that a similar function is already available
> in avahi's core and people who make direct use of DBUS from something
> that is not C/C++ (without going through avahi-client) might need it.
> 
> I hope this would satisfy your needs?

Yeah.  That sounds good.  However, your suggestions do bring my
attention to an alternative solution, at least for my purposes.

In my situation, I am resolving immediately, because I need some of the
TXT records before I determine how to use the service.  I hadn't
considered that I could just add my own TXT record to my own service
that would identify it well enough.  So I think I'll switch my code over
to do it this way until what you're describe makes a release.

Thanks a lot,
-charlie