Re: getnameinfo and various protocol types

[Peter Lei <peter.lei@ieee.org>]

Jun-ichiro itojun Hagino wrote:
> > > 	SCTP supports both SOCK_DGRAM, SOCK_STREAM as well as SOCK_SEQPACKET.
> > SOCK_STREAM sounds odd since SCTP doesn't provide a byte stream service - it
> > provides a service that has explicit message boundaries.
>
> 	SCTP do provide three models (SOCK_xx).
> 	draft-ietf-tsvwg-sctpsocket-07.txt talks about it more (it talks about
> 	SOCK_SEQPACKET and SOCK_STREAM only, but the reference implementation
> 	from rrs@cisco on KAME do provide SOCK_DGRAM too).
Yes, our reference implementation on KAME originally used SOCK_DGRAM
for the one-to-many API... that is technically incorrect since the
SCTP socket API calls out SOCK_SEQPACKET and SOCK_STREAM; I'm sure
we'll remove the SOCK_DGRAM use at some point.

The SOCK_STREAM use in the API draft is for backward compatibility
to TCP and a "migration" path for existing applications:

ie. change socket(AF_INET{6}, SOCK_STREAM, 0) to socket(AF_INET{6},
SOCK_STREAM, IPPROTO_SCTP) and you will get an "equivalent" functionality
(from the application perspective at the sockets interface) over SCTP.

> > > 	DCCP should be SOCK_DGRAM only, if i understand correctly.
> > Also odd; you mean socket(AF_INET, SOCK_DGRAM, 0) might provide a DCCP
> > socket on systems that support DCCP? Or IPPROTO_DCCP would need to
> > be explicitly specified?
>
> 	could be, but for backward compatibility's sake i guess 0 would give
> 	you IPPROTO_UDP socket.
>
>
> > > 	therefore, there's no 1-by-1 mapping from SOCK_xx to IPPROTO_xx.
> > > 	to clarify, i agree there should be some way to support non-inet
> > > 	protocols, however i'm not sure how service lookup works for non-inet
> > > 	protocols.  do people have any examples (such as appletalk or whatever)?
> > I think that is what we need to figure out.
> >
> > Problem is that the socket() call takes both a type and a protocol argument
> > and getnameinfo() has a single NI_DGRAM which implementations map to
> > the single protocol argument in getservbyport().
> >
> > But this reminds me; doesn't SCTP use the same port number space as TCP?
>
> 	basically the same space, but they do have separate entries on
> 	/etc/services and http://www.iana.org/assignments/port-numbers.
> 	for instance, http is only defined for http/tcp and http/udp at this
> 	point of time.  only a limited number of sctp services are defined on
> 	IANA assignment page.
>
> 	and since we have "foo/sctp" on /etc/services, we need to pass
> 	"sctp" as 2nd arg to getservbyport(3).
Actualy, RFC2960 explictily states that "All current TCP ports shall be
automatically reserved in the SCTP port address space." in the IANA
considerations section.

--peter

> > Will DCCP use the same port number space as either TCP or UDP?
>
> 	IANA assignment page has no entry for dccp yet, so i'm not sure.
>
>
> > The getnameinfo() man page seems to claim that NI_DGRAM is only needed
> > because there are a few ports which are used for different protocols in UDP
> > and TCP:
> >
> >     A fifth flag bit, NI_DGRAM, specifies that the service is  a
> >     datagram  service,  and  causes getservbyport(3SOCKET) to be
> >     called with a  second  argument  of  "udp"  instead  of  the
> >     default  "tcp".   This  is  required  for the few ports (for
> >     example, 512-514) that have different services for  UDP  and
> >     TCP.
> >
> > If this isn't going to be an issue for SCTP or DCCP maybe we don't
> > need to change anything.
>
> 	it is going to be an issue.  in fact, it already is.
>
> itojun
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------