Subject: Re: sctp_peeloff()

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Wed, 10 Dec 2003 17:16:43 -0600

Xiaodan Tang wrote:

> I would expect this could be an application error. It should always 
> have other threads waiting on other stream.  If you are single thread 
> application, you should never call
> stream specific sctp_recvmsg()? 

Ok,

I write a multi-threaded app.. and somewhere along the line
a sender is pumping out messages faster than a thread
wants to read the messages.. the other threads want the
data at a faster rate... the slow one will block the faster
consumers.. this is the crux of the problem.. and your restrictions
above do not solve it.

R

>
>
> Regards
> -Xiaodan
>
> Michael Tuexen wrote:
>
>> 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
>>>   
>>
>
>