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

['Raimo Niskanen']

On Fri, Apr 24, 2009 at 03:27:53PM +0200, Valentin Micic wrote:
> 
> > 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?

Yes it would. Thank you for the pointout. Nobody has claimed
much interest in SCTP accept() before.

> 
> > 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
Phew!
> 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

{active,once} with message dispatching in the port owner process
is probably sufficient for most cases. Combining it with
branched-off associations would make flow control not
affect unrelated associations. And {active,Stream,Pid}
would optimise message dispatching, loosing flow control.

The question remains if {active,true|false|once,Stream,Pid}
with the side effect that while any stream processor is active
data flows in on all streams and is buffered in the
dispatcher (Port or PID) - only if all stream processors are
passive would the flow be blocked, would be useful?
That would be a complicated concept. What do you think?

> 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. 

I need to discuss this to get branched off associations
(and streams) right, so thank you for your input. It is so
easy to accidentaly choose a model that eventually proves
to destroy the best model for a later feature introduction...

> 
> > 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?

... One-to-many associations. Multi-homed endpoints. Packeted messages...
Those would be important for the Distributed Erlang protocol.
It is unclear if the streams would be useful.

> 
> V

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB