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

['Raimo Niskanen']

On Thu, Apr 23, 2009 at 07:15:16PM +0200, Valentin Micic wrote:
> > But I am now under the assumption that a stream separation
> > that does not utilize additional file descriptors
> > (as you ask for) can not do per-stream flow control
> > (with respect to remote peer) and therefore is not useful.
> 
> > Prove me wrong and I might do it.
> 
> Proving you wrong may take some time. :-)

I am starting to realize I have mixed the stream and the
association concepts a bit in my head...

> 
> AFAIK, flow control is explicitly defined only at association level. Having
> said that, please note that each data-chunk (hence stream traffic) has to be
> individually acknowledged -- if acknowledge is not received, sender will not
> send more data for a given stream. Unfortunately, this will not prevent
> sender to send the same data chunk again, confusing a lack of
> acknowledgement for a loss of a chunk...
> I need to read a bit about it, however, not sure if any amount of reading
> can help me here.

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

> 
> But more importantly than proving you wrong:
> I know that you would be able to use a separate file descriptor to move a
> specific association from one-to-many to one-to-one socket. That association
> may have more than one stream (which would typically be a case), so you're
> back to where you were with respect to {active, once} and head-of-line
> blocking. Don't know how this can be done for individual stream (assuming
> that file descriptor = socket).
> 

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.

In that case, is there any way to avoid head-of-line blocking
within an association? So far I have heard of none. In fact
I have heard that streams are mostly avoided due to their 
pecularities.

So we can get a (socket) driver that dispatches streams
or association:stream for one-to-many sockets to registered
processes on reception, and probably that sets association:stream
when a registered process sends. But it will only work
for {active,true}. A more advanced variant would be to
simulate {active,once} and {active,false} by receiving
and buffering any amount of messages until all registered
stream processors do not want any message.

Is stream dispatching for only {active,true} useful?

Is stream dispatching with emulated {active,true|false}
that may have to buffer any amount of messages (or rather
application dependent amount) under the hood useful?


> 
> Regards,
> 
> V.

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB