Subject: Re: sctp_peeloff()

From: Caitlin Bestler <[email-masked]>
Date: Tue, 9 Dec 2003 15:51:53 -0600

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.

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

But that is inconsistent with socket semantics, where data
is held  "somewhere" until the application asks for it.

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