[erlang-questions] : : : : : sctp_peeloff() support in OTP

[Valentin Micic]

> So, we can get per association flow control, and
> that is the best flow control we can get. By implementing
> branched-off associations (sctp_peeloff()).

If I may add: there is a much more traditional way to implement one-to-one
socket, and that is by implementing accept() socket call (see paragraph
4.1.4 of http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-13 ). The
sctp_peeloff() is an advanced SCTP specific call, hence not so intuitive for
a "traditional" socket programmer. Whilst this might not be a problem, there
is one feature of sctp_peeloff which bothers me about it. Unlike accept(),
which can guarantee that all the traffic is exchanged between two intended
SCTP endpoints (one-to-one socket); with sctp_peeloff() nothing can ensure
that port owner, which was handling one-to-many socket before peeloff
happened; did not handle a bit of the traffic itself. Wouldn't it make more
sense to implement accept before (or alongside) sctp_peeloff?

> I hope I never actually suggested to use one file descriptor per
> stream, I do not think it is possible; one file descriptor per
> association can be done.

I do not think you did... I could have made that association (no pun
intended) myself, as I've been trying to talk about streams within
particular association and regardless of association identifier and/or
socket style used. 

> In that case, is there any way to avoid head-of-line blocking
> within an association? So far I have heard of none.

Remember that SCTP driver already prevents head-of-line blocking. The
problem was that {active, once} issued against port would reintroduce it if
the port owner is to process all the messages, thus creating processing
delay. Funny thing is, after all that has been said I'm thinking: so what if
it does... One may have a port owner that only dispatches the traffic
to-and-from the port, and how much of the processing delay that may really
create?
In that respect, {active, once} is still useful, as it would protect
run-time from uncontrollable process message queue build-up, which degrades
erts performance. And the best thing is -- all of that may be achieved
without messing with the driver. Sorry to take up so much of your time. 

> In fact I have heard that streams are mostly avoided
> due to their pecularities.

If you remove "S" from "SCTP" you're left with "CTP", which looks like a TCP
with letters arriving out of order. What would be the point of SCTP support
if we do not use what it was designed for?

V