Subject: Re: sctp_peeloff()

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

Caitlin,

see my comments below.

Best regards
Michael

On Dec 9, 2003, at 10:51 PM, Caitlin Bestler wrote:

>
> 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.
>>
>
>
> That is one more strong point on the "gotchas" of attempting
> to do per-stream processing with a synchronous API.
>
> I still think that per-stream buffering is very useful, but
> it needs to be done in a way where the failure to provide a
> buffer for a given stream prevents a Data Chunk from being
> delivered to the application.
>
You can do per stream buffering on the sender side easily...
> With RDMA style interfaces the solution to this problem is
> very simple, streams MUST pre-post sufficient buffers. Failure
> to do so will result in the stream being reset (which allows
> the TSN to advance).
What does reset a stream mean in RFC 2960?
>
> But that is inconsistent with socket semantics, where data
> is held  "somewhere" until the application asks for it.
>
This is how it is done in the socketapi currently.
> Given that applications SHOULD take delivery of all data
> within an association promptly then having "per stream"
> sockets is indeed dangerous. That suggests that stream
> specific processing is best achieved through a callback
> or RDMA style interface.
>
>
> -- 
> Caitlin Bestler - [email-masked] - http://asomi.com/
> http://asomi.com/CaitlinBestlerPublicPgpKey.html
>