tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: getaddrinfo: how to wildcard everything?

>> So I'm wondering if anyone here has enough insight into the design
>> decisions behind getaddrinfo() to know what the designer(s) intended
>> people use to do what I'm trying to do here: bind a port-0 (or moral
>> equivalent) socket in each supported address family.
> I am not going to claim to any particular insight, but I suspect that
> the mindset might have been that there were a few uses for
> getaddrinfo() imagined, but enumerating address families was not one
> of them.

Not enumerating address families per se, but binding to a
kernel-selected port in each supported address family.

> I'm not sure it is worth it either ... there are just 2 (IPv4 and
> IPv6) the moment...

> and if a new one were added, any code written to deal with those two
> would need to be modified to handle something different, almost
> certainly.

Most of my uses of getaddrinfo() don't need to do anything with
->ai_family beyond passing to to socket().  I was hoping - and, I must
admit, expecting - that this would be just another such.

> So, in practice, no-one wants to look up nothing, just to find out
> what address families exist (if an implementation doesn't support one
> of the two, you'd discover that on attempted use).

No, it's not just to find out what AFs are supported.  It's to bind a
wildcard socket (port 0 or moral equivalent with address INADDR_ANY or
:: or moral equivalent) in each of them (and then use getsockname and
getnameinfo to report the address it got bound to).

> But for a hackish kind of solution to your problem, nothing says that
> you are required to use the address structures returned from
> getaddrinfo() unaltered - they're not opaque.

If you don't want to write AF-specific code, they might as well be.

> So, you can just look for some random well known service (telnet,
> ftp, http, echo, ...) and when you get the results back, simply
> overwrite the port number field with the 0 you wanted to get
> returned.

Even _finding_ the port number requires looking at the address family
(whether in ai_family or ss_family) and writing AF-specific code for
each AF.  That's what I was trying to avoid.  See also my next

> You could also just try "0" as the service name, though I'm not sure
> how portable that would be, if it works.

It would, at a minimum, be specific to service implementations being
small integers, as opposed to, say, DECnet, where they are (short)
strings instead, with the equivalent of port 0 - if there is one! -
being, I don't what, maybe a zero-length string?  This is another
reason why just overwriting the port number involves AF-specific code:
what to overwrite it with is AF-specific.  It's just an API/ABI design
similarity that means 0 is appropriate for both AF_INET and AF_INET6.
(For that matter, I don't see anything in 793 that singles out port 0
for anything special, nor do I think there should be; I call it an
API/ABI design bug that it's special to the socket layer.  "Kernel
selects port" should be indicated in some out-of-band way, not by a
distinguished in-band value.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Home | Main Index | Thread Index | Old Index