Subject: Re: sctp_peeloff()

From: Xiaodan Tang <[email-masked]>
Date: Wed, 10 Dec 2003 11:56:13 -0500

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