Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Jul 2001 18:44:39 +0100
From:      Ian Dowse <iedowse@maths.tcd.ie>
To:        itojun@iijlab.net
Cc:        freebsd-net@FreeBSD.ORG, Bernd Walter <ticso@mail.cicely.de>, Hajimu UMEMOTO <ume@mahoroba.org>
Subject:   Re: how to get AF_LOCAL from getaddrinfo() 
Message-ID:   <200107161844.aa52089@salmon.maths.tcd.ie>
In-Reply-To: Your message of "Tue, 17 Jul 2001 00:56:55 %2B0900." <14832.995299015@itojun.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <14832.995299015@itojun.org>, itojun@iijlab.net writes:
>	i still am not getting your motive...  do you have actual applications
>	that use getaddrinfo/getnameinfo for AF_UNIX?

The main purpose is to allow code using AF_UNIX sockets to do so
without having to deal with the internals of the sockaddr_un
structure. This is particularly useful for programs such as telnet
and rpcbind that already support multiple protocols, but they must
deal with AF_UNIX sockets completely separately because getaddrinfo
does not support it. They will still need to do the unlink() etc
with getaddrinfo support, but at least the logic can still be based
around storing sockaddrs in 'struct addrinfo' structures instead
of having completely different data structures for the AF_UNIX
case.

For getnameinfo, the AF_UNIX case does not require any special
handling by the application; the only question is what to return
as the hostname.

>	but still - how many special case behavior do we want to put?
>	there are a lot of other AFs... which item is included in AF_UNSPEC
>	and which are not?  if we want uniformity, we will break existing apps.
>	if we don't want to break existing apps, we need to drop uniformity.
>	it is a hard question to ask...

I think only protocols where the resulting sockaddr can be passed
directly to bind() or connect(), and that have an unambiguous way
to specify the protocol via host/service, should be included in an
AF_UNSPEC search. At the moment, that pretty much means just INET
and INET6.

This approach also appears in the protocols listed by /etc/netconfig
which are used by TI-RPC; only udp4, udp6, tcp4, tcp6 are marked
as "visable" protocols; the others are supported, but you have to
explicitly ask for them.

As to the other AF_* protocols, I don't think any of them are used
as widely as AF_UNIX in FreeBSD. If support were to be added to
getaddrinfo for some of the more obscure protocols, it could probably
be #ifdef'd out by default.

Another important reason to add this feature is for compatibility
with other platforms' getaddrinfo() implementations. I just tried
a random Linux box here, and it seems to have very similar behaviour
to that implemented by my patch. There is also the general idea
that the way to encourage people to use a "preferred" interface is
to make it useful in as many situations as possible :-)

Ian

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200107161844.aa52089>