Subject: Re: sctp_peeloff()

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Tue, 09 Dec 2003 12:09:22 -0600

Michael:

Interesting point... but is not the problem NOT
that the cum-TSN cannot be forwarded... you can
always ack the data even though the receiving stream
is holding off reading.. but the issue is more how
does one manage the rwnd in this situation... I think
this is where you are going... If socket a-stream-1 stops
reading and socket a-stream-2 is reading.. then it is possible
that a-stream-1 will hold all of the rwnd and thus block the
association... Since we have no way to apportion the rwnd per
stream this is a problem..

R

Michael Tuexen wrote:

> Hi all,
>
> i think having a fd for a stream is a real problem. If the
> user 'decides' not to read from a particular stream because
> there is a separate thread/process for it which is blocked
> the receiver can not forward the cumulative TSN and therefore
> blocks the whole association.
>
> The receiver should always return in the receive call the
> (part of) a DATA chunk with lowest TSN.
>
> Best regards
> Michael
>
> On Dec 9, 2003, at 12:36 PM, Randall Stewart (cisco) wrote:
>
>> Kacheong Poon wrote:
>>
>>> I'd like to gather opinions about making sctp_peeloff()
>>> work in one-one style SCTP socket.  The semantics is
>>> creating a new socket for a particular stream of an
>>> association. The stream number will be passed in the
>>> place of the assoc_id in the current sctp_peeloff().
>>>
>>> Do people think that their apps can benefit from this?
>>> Thanks.
>>>
>> Hmm... There does seem to be some interest (at least
>> I have been contacted privately several times) on making
>> it so that you can read from a particular stream...
>>
>> I don't think I would be opposed to this... it will be a bit
>> of code for me, but has you have said .. its just code... and
>> it may well be quite useful...
>>
>> Let's see what other developers think... I could go for it :->
>>
>> R
>>
>
>