[PATCH] Allow getaddrinfo() to accept SCTP socket types in hints

[Ulrich Drepper]

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.

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?


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.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖