Subject: [Tsvwg] Adding recv_msg() from specified stream

From: Florian Niederbacher <[email-masked]>
Date: Wed, 05 Nov 2008 20:42:06 +0100

Hello,
at the moment there is no way to specify from which SCTP stream to read? 
If data is ready on any stream, then you have to read it.
The intention is to avoid that data could be blocked on a stream with no 
one to read it, which eventually could fill up system buffers, and 
result in a HOL- blocking.
There are the extended sndrcv info field to figure out form which stream 
you are reading next. But is not so comfortable.

But what are the reasons not to have different buffers in Kernel space 
for each stream? I guess it could be useful to define a function 
interface e.g. recv_msg_from_stream().
Otherwise every software developer has to always to implement the own 
receiving functionality (reading and buffering). My opinion is, that a 
better way is offering an implemented method in the SCTP socket API. 
What are your suggestions?

Best regards
Florian Niederbacher

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 5 Nov 2008 21:24:27 +0100

On Nov 5, 2008, at 8:42 PM, Florian Niederbacher wrote:

> Hello,
> at the moment there is no way to specify from which SCTP stream to  
> read? If data is ready on any stream, then you have to read it.
> The intention is to avoid that data could be blocked on a stream  
> with no one to read it, which eventually could fill up system  
> buffers, and result in a HOL- blocking.
> There are the extended sndrcv info field to figure out form which  
> stream you are reading next. But is not so comfortable.
>
> But what are the reasons not to have different buffers in Kernel  
> space for each stream? I guess it could be useful to define a  
> function interface e.g. recv_msg_from_stream().
It is not just define a function. I think current implementation put  
messages which can
be delivered in a socket buffer and the user reads from that buffer.
So it would mean that you change a lot more than just providing  
another function...
>
> Otherwise every software developer has to always to implement the  
> own receiving functionality (reading and buffering). My opinion is,  
> that a better way is offering an implemented method in the SCTP  
> socket API. What are your
Why does every developer need to implement this?

The selection of the stream is a sender side issue and (from my point  
of view) the receiver
should actually not care on which particular stream a message is  
received. By selecting the
stream the sender just makes sure that messages which have to be  
delivered in sequence
are delivered in sequence.
> suggestions?