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


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


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