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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
