[PATCH] Allow getaddrinfo() to accept SCTP socket types in hints
Sridhar Samudrala
sri@us.ibm.com
Thu Oct 19 17:59:00 GMT 2006
On Thu, 19 Oct 2006, Ulrich Drepper wrote:
> Rick Jones wrote:
> > Not knowing any better about the code or its history I'll ask what might
> > be a stupid question - is there a middle ground where passing-in zero
> > doesn't get one SCTP entries, but passing-in IPPROTO_SCTP would actually
> > return some?
>
> In theory, yes.
>
>
> But why would anybody use getaddrinfo for sctp? The nice thing about
> getaddrinfo is that it can be used uniformly. The client and server
> code to use the results is quite simple. See the examples in
>
> http://people.redhat.com/drepper/userapi-ipv6.html
>
> Now throw SCTP into the mix and suddenly it becomes ugly. All of a
> sudden the connect and bind calls need to be different. sctp_bindx must
> bind multiple addresses, sctp_connectx must connect to multiple
> addresses. You have to pass an array of sockaddr elements. This is not
> provided by getaddrinfo(). Constructing them is extra work not needed
> for normal getaddrinfo() uses.
You seem to be assuming that all SCTP apps need to use sctp_bindx() and
sctp_connectx() to establish a multi-homed association. This is not true.
Most of the apps would simply use the existing bind() and connect()
interfaces. The addresses are exchanged in the INIT/INIT-ACK by the protocol
and need not be passed by the user.
sctp_bindx() and sctp_connectx() are extensions that would be useful if a
user wants to restrict the set of addresses.
>
> I haven't looked too much at all this. Which is also why I still wonder
> how on earth can sctp_bindx and sctp_connectx survive with a parameter
> of type struct sockaddr*. Are the interfaces supposed to recognize the
> size of the actual array elements by looking at the type? What about
> mixing AF_IENT and AF_INET6 addresses?
These interfaces take an array of socket addresses and a count of the
addresses. For AF_INET6 socket, the array elements are of type sockaddr_in6
and it can have both v4 and v6 addressess. For AF_INET sockets they are
of type sockaddr_in.
>
> What all this shows is that I think there are two possible solutions:
>
> - stay with the current libsctp but add a special sctp_getaddrinfo
> functions. It really makes no sense to mix it with the normal uses
>
> - redesign the SCTP bind and connect interfaces. They should accept a
> list of struct addrinfo element which can be retrieved from
> getaddrinfo. Maybe the interface should automatically filter out
> address types not matching the use (i.e., if an UDP socket is wanted
> all IPPROTO_TCP and IPPROTO_SCTP records are ignored). The bind
> replacement would bind to all addresses, the connect interface would
> use the first one which can successfully be used. The interface
> should be generic to also accommodate UDP, TCP, ...
>
>
> I would very much prefer the second route. All this can likely be
> hidden in userlevel code, no kernel changes needed. And if we can iron
> out the details I can also take these new interfaces up with POSIX.
I am not sure what is the current status and plans of getting these interfaces
to POSIX. So i am including sctp-impl mailing list so that the authors of
the API draft can respond.
Thanks
Sridhar
More information about the Libc-alpha
mailing list