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

[Vlad Yasevich <vladislav dot yasevich at hp dot com>]

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? 

To keep a consistent program model for a program that decides to support
SCTP in addition to TCP and/or UDP.

> 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
> 

Yes, but this is just one method.  getaddrinfo() is being pushed as
a uniform name resolution API.  If one has a name and service/port,
call getaddrinfo() with any tunning knobs you want and get a filled-in
sockaddr of the correct size.

> 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,

no, it can be give just one.

> 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.
> 

Actually, for bindx() is is really easy.  Just loop over the list returned
to you from getaddrinfo() and call bindx on each address.

For connectx() it's a little more complicated, but not many apps use connectx().
Most applications will be more then happing to just loop over the address list
returned and call connect().

> 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?
> 

I think Sridhar answered this one.

> 
> 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
> 

This would be ugly.

> - 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.

I don't think this is really needed.  What's needed is a protocol independent
name resolution interface that works for SCTP.  Guess what, that getaddrinfo(),
since getipnodebyanme() and gethostbyname2() have been deprecated.

So, right now, we are stuck with not setting the socket type in getaddrinfo(), and
then munging the returned ai_socktype with what we really needed.  That's a PITA.

If I tell getaddrinfo to use a given socket type and protocol type, it should use it
to fill in the results an not give me grief.  Now, if I doesn't provide those
fields, getaddrinfo() is free to return whatever it supports.

-vlad