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)
...at 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
paragraph.
> 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 mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index