[erlang-questions] SCTP support (was EPIPE and TCP sockets)

[Per Hedeland]

Bruce Fitzsimons <Bruce@REDACTED> wrote:
>>   
>Throughput is unlikely to be a benefit; considering we have many years 
>experience in TCP behaviour and tuning and not much at all with SCTP. 
>SCTP is a more complex protocol, but does avoid several TCP corner cases 
>including head of line blocking 
>http://en.wikipedia.org/wiki/Head-of-line_blocking.

Hm, I can't quite see how that relates to TCP vs SCTP. Presumably you're
not actually referring to the situation in a network switch (i.e. layer
2 device), since the upper-layer protocol won't make a difference there?
I can see how this phenomenon could occur with "naive" multiplexing of
multiple "channels" on a single TCP session, like, um, the Erlang
distribution does (though I can't see it happening with Erlang
distribution since the "channels", i.e. inter-process messages, won't be
blocked at the receiving end) - is that the connection?

Of course this can be handled by per-channel flow control (like e.g. SSH
does) when using TCP, but I guess this user-level complexity can be
avoided by using SCTP instead.

>I am most interested in SCTP to take advantage of the native connection 
>heart-beating, something commonly implemented in the application layer 
>but not present as standard in XMPP. With the "standard" TCP connection 
>timeout at 2 hours the TX buffer can be filling on the sending host 
>without the application being aware that they are not being delivered, 

The 2 hours would be for the (misnamed) keep-alive functionality in TCP
- if there actually is output data waiting to be ack'ed, the "standard"
timeout before the connection is declared dead is generally much
shorter, on the order of 5 minutes or so - though of course that can
still be "way too long" in some cases.

>and there is no way to tell what quantity of data was reliably delivered 
>when the connection is finally terminated (Tony's problem).

Yes, but that's the same story as we've frequently discussed here
regarding whether Erlang distribution is "reliable" - if you *really*
want *reliable*, knowing that the data was successfully received by the
network stack at the destination is only the first chapter in that
story...

--Per Hedeland