This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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 â


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]