Subject: Re: sctp_peeloff()

From: Michael Tuexen <[email-masked]>
Date: Wed, 10 Dec 2003 22:09:44 +0100

The is the same problem: You call a blocking sctp_recvmsg for stream 0.
You get/have a lot of messages for stream 1 which fill up the receiver
window. Now you are in a deadlock situation.
The only way is on the receiving side accept the user data with the 
lowest
TSN involved.

Best regards
Michael

On Dec 10, 2003, at 5:56 PM, Xiaodan Tang wrote:

> Instead of "peel_off()" a stream, how about allow sctp_rcvmsg() to be 
> able to
> receive from a perticular steam_id ?  As of now, we can sctp_sendmsg() 
> to a
> specefic stream, but not receive on it.
>
> -xtang
>
> Andreas Jungmaier wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi folks,
>>
>> to add up to the discussion:
>> in cases where there is only an outgoing stream, but no incoming 
>> stream, applications can only send, not receive
>> on a "stream-socket".
>> In the opposite case, an application could only receive,
>> but not send.
>>
>> I don't know if that's a problem, since that can happen
>> as well with some streams within an SCTP association.
>>
>> However, I don't really like this idea.
>>
>> Best regards,
>> Andreas
>>
>> On Wednesday 10 December 2003 11:07, Kacheong Poon wrote:
>>
>>> Randall Stewart (cisco) wrote:
>>>
>>>> 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..
>>>>
>>> This can be an issue.  If an app chooses to peel off a
>>> stream, it has to be careful in handling the individual
>>> stream-socket to avoid blocking of other streams.  But
>>> this also opens up the socket interface for people to play
>>> with streams scheduling.
>>>
>>> Any idea on how to make it safer?
>>>
>>>
>>>> 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
>>>>>>
>>
>> - -- Dipl.-Ing. Andreas Jungmaier              Computer Networking 
>> Technology Group     University of Duisburg-Essen                     
>>   http://www.exp-math.uni-essen.de/~ajung   PGP Key-ID: D382 4AC0
>> PGP Key-Fingerprint: 228C 7C2C 3381 2DD4  9998 2812 5C0B 0B04  D382 
>> 4AC0
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.2.3 (GNU/Linux)
>>
>> iD8DBQE/1vLKXAsLBNOCSsARAjVDAKDRlPy3Hkg8KUFbu31DjUFJ5ca1sQCglS3Z
>> P5d8fnU5Jq3z+E+nB0Fn4IM=
>> =/AL3
>> -----END PGP SIGNATURE-----
>>
>>
>