[erlang-questions] SCTP support (was EPIPE and TCP sockets)
Sat Oct 13 17:40:59 CEST 2007
Thank you, that was a very helpful answer.
I understand the 'advertising' feature list for SCTP, but I've never
appreciated the issue you explained.
I'd only skimmed http://tools.ietf.org/html/rfc3286, and I'd not
noticed anything about 'heart-beating' until now either (9.1 and
9.2e), so that was great!
I strongly agree that it's a bit early to deploy SCTP in an hostile
environment, unless there are *critical* benefits that outweigh the
risks (and you can manage the risks :-).
Anybody - On a related track, do all Erlang messages between two
specific Erlang nodes go down one socket?
[I thought the response to my question would be out-of-order delivery
being the killer SCTP feature, but maybe that isn't an issue].
> Date: Sat, 13 Oct 2007 22:45:18 +1300
> From: Bruce Fitzsimons <Bruce@REDACTED>
> Subject: Re: [erlang-questions] SCTP support (was EPIPE and TCP
> To: G Bulmer <gbulmer@REDACTED>
> Cc: "Erlang-Questions \(E-mail\)" <erlang-questions@REDACTED>
> Message-ID: <471093AE.3060600@REDACTED>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> G Bulmer wrote:
>> Newbie question.
>>> Date: Fri, 12 Oct 2007 12:29:41 +1300
>>> From: Bruce Fitzsimons <bruce@REDACTED>
>>> Subject: Re: [erlang-questions] EPIPE and TCP sockets
>>> ... I'd still like to
>>> use the SCTP support in Erlang to demonstrate XMPP over SCTP and see
>>> what sort of improvements it might give, ...
>> Is the "Erlang SCTP support" likely to give higher message
>> throughput, or is this really about reliability guarantees? Is this
>> OS sensitive, i.e. very much bound to the quality of SCTP
>> implementation for the underlying OS?
> 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
> including head of line blocking
> Given that it is most used in friendly environments, I think we are
> still to see what new DoS attacks SCTP could enable, but the TCP ones
> are fixed and thought was given to preventing new ones.
> I am most interested in SCTP to take advantage of the native
> heart-beating, something commonly implemented in the application layer
> but not present as standard in XMPP. With the "standard" TCP
> 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,
> and there is no way to tell what quantity of data was reliably
> when the connection is finally terminated (Tony's problem). This
> manifests in XMPP as messages being silently blackholed and presence
> information that is way out of date. This only occurs when the
> disappears rather than terminates the TCP connection but this is
> common on the Internet. (I'm quite likely to be corrected here, in my
> defense my Stevens is at work and the failure cases are subtle.) Most
> XMPP implementations reduce the timeout length but this can never be a
> complete solution.
More information about the erlang-questions