[erlang-questions] Re: SCTP accept?
Mon Sep 21 01:37:41 CEST 2009
Strictly speaking, SCTP doesn't really have an accept at the protocol
level. It only has associations. While the protocol has a
specification (RFC 2960), the socket API is only a draft. The draft
does specify an accept function, but it's only for convenience of
people who write imperative, heavily state-laden code. Since the
protocol doesn't really have an "accept" at the low-level, it's all
really mental acrobatics on the part of the Socket API.
The Erlang implementation appears to use the API that fits SCTP's
primary use-case. Associations happen automatically if you're
listening, and you can kill them if you don't like them. I don't have
a working SCTP deployment to play with right now, but I'm pretty sure
that new associations come in as assoc_change events when you're
I've looked at two implementations; one in Python (pySCTP) and one in
Java (javaSCTP). The Java one does not have an accept function. The
Python one does. The Socket API draft goes so far as to have two
types of SCTP-sockets, a one-to-many-style socket, and a one-to-one-
At a protocol level, SCTP just forms associations. You can ask it to
do so, and the behavior of the server isn't exactly specified. In the
Socket API draft, they suggest that one-to-many sockets should
automatically accept associations (like UDP does), and one-to-one
sockets are either accepted explicitly (like TCP) or peeled off of a
many-to-many socket using sctp_peeloff (unlike anything else at all).
I personally think that this draft does a good job at enabling people
to use SCTP in completely the wrong way. I think it's what happens
when people who think in terms of threaded, stateful code work with a
protocol that's good for stateless, event-driven coding. Basically,
This is all largely because the use-case for SCTP is very different
from the one for UDP or TCP. TCP is largely made for individual
connections where a single server and single client have a meaningful
relationship in a stream of bytes that ends when the connection
closes. UDP is largely made for extremely unstructured blasting of
stateless records of data between arbitrary combinations of hosts.
SCTP is made for blended situations where a mesh of clients and
servers blast stateless records to each other, interleaved with
ordered streams of records.
As an example of *the* SCTP use-case, consider tunneling phone-switch
data over the internet. You may have a dozen phone switches, each
blasting each other with streams of events that must be processed in a
certain order. You may have multiple streams, e.g. control
information (allocate this line, this line is ringing), load
information (I'm loaded, route around me), messaging information (here
are some SMS messages). On the other hand, there may be diagnostic
information that is sent completely outside of any stream (I'm
shutting down, I had a hardware fault, etc).
Each of these might be of relative importance. Each of these
typically will take the form of records of a specific size. Some of
these should be ordered with respect to each other, but not all of
them. This is where TCP falls down and SCTP shines.
For TCP, each ordered stream would be a different connection between
the machines. Each connection could be lost and would have to be re-
established. If you were to multiplex multiple connections in a
single TCP connection, you get head-of-line blocking problems. When
you have record oriented data, you have to frame it with data
structures to tell when one record ends and the other begins. If you
get out of sync, the only way to resynchronize reliably may be to kill
the connection. It's just not optimal.
With SCTP, you simply initiate associations and watch for data /
events. Data shows up in neat packets, marked with their source.
Streams are neatly independent. There is no need to do framing.
There are no head-of-line problems that you don't create for
yourself. There is no management of associations, they just form and
break as is possible.
On Sep 20, 2009, at 11:29 AM, Steve Davis wrote:
> ...prim_inet doesn't even appear to have accept support for anything
> but TCP. Does this mean the Erlang SCTP implementation is worthless
> for any real use?
> I'm beginning to wonder if the "UDP-like" nature of SCTP has been
> misunderstood in the actual Erlang implementation. SCTP, like TCP, is
> connection-oriented and therefore you do need the accept step to allow
> multiple clients. Other api implementations eg python/java that I
> checked over do require this step, so it seems to me that perhaps the
> offering in Erlang isn't complete??
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
More information about the erlang-questions