[ntp:questions] Pool returns IPv6 address to IPv4 query
Uwe Klein
uwe at klein-habertwedt.de
Wed Nov 20 22:05:59 UTC 2013
Rob wrote:
> Brian Utterback <brian.utterback at oracle.com> wrote:
>
>>On 11/19/2013 3:40 PM, Danny Mayer wrote:
>>
>>>You should not be using literal IP addresses of either flavor without
>>>also setting the AI_NUMERICHOST flag otherwise it tries to do a DNS
>>>lookup. That's poorly written code otherwise.
>>>
>>>Danny
>>
>>Not so. The getaddrinfo function will recognize literal addresses and
>>merely convert them. The point is that for something like ssh or any
>>other network utility, the user is supposed to give a hostname, but in
>>virtually all cases you can give a literal address and the application
>>does not have to treat it differently. If you read the ipng mailing
>>list, you will see that they were trying to make the whole process of
>>writing a network application simpler, with getaddrinfo doing the heavy
>>lifting for all of the major cases. At the same time they were trying to
>>allow applications to work on either IPv4 or IPv6 systems without
>>changing them, or dual stack or any combination. But no matter what they
>>did there were edge cases that needed to work differently.
>>
>>Brian Utterback
>
>
> Well most of it was successfull, I converted an application from the
> old functions to getaddrinfo/getnameinfo etc, and it really is more
> convenient to program for.
>
> However, what I don't understand is why an IPv6 address does not fit
> into a struct sockaddr, and why this fact is so badly documented.
> It took me a lot of time to find why my queried IPv6 addresses were
> truncated.
struct sockaddr was a catch all and you had to also hand the size of the
storage into the call.
forex:
int getpeername(int s, struct sockaddr *name, socklen_t *namelen);
if you look into sys/socket.h
# define __SOCKADDR_ALLTYPES \
__SOCKADDR_ONETYPE (sockaddr) \
__SOCKADDR_ONETYPE (sockaddr_at) \
__SOCKADDR_ONETYPE (sockaddr_ax25) \
__SOCKADDR_ONETYPE (sockaddr_dl) \
__SOCKADDR_ONETYPE (sockaddr_eon) \
__SOCKADDR_ONETYPE (sockaddr_in) \
__SOCKADDR_ONETYPE (sockaddr_in6) \
__SOCKADDR_ONETYPE (sockaddr_inarp) \
__SOCKADDR_ONETYPE (sockaddr_ipx) \
__SOCKADDR_ONETYPE (sockaddr_iso) \
__SOCKADDR_ONETYPE (sockaddr_ns) \
__SOCKADDR_ONETYPE (sockaddr_un) \
__SOCKADDR_ONETYPE (sockaddr_x25)
you'll see that there is a range of possible returns depending on protocol.
uwe
More information about the questions
mailing list