Subject: Re: sctp_peeloff()

From: Michael Tuexen <[email-masked]>
Date: Wed, 10 Dec 2003 21:59:37 +0100

Caitlin,

I think you are using the streams in a way they are (initially)
not intended for. The problem is that you have only a
per association receiver window, not a per stream. So
it is very likely that one processing entity will block
the other.

On the other hand i do not see the usage of this. If you need a
demultiplexer of some sort you might want to do it above SCTP.

Best regards
Michael

On Dec 10, 2003, at 11:14 AM, Kacheong Poon wrote:

> Caitlin Bestler wrote:
>
>> There is a major benefit to being able to use stream
>> specific buffers when reading.
>> But with the sockets API that has to be weighed against
>> the overhead of using poll/select to find out which
>> stream has supplied the buffer.
>> If you migrate to more of an asynchronous interface,
>> I believe the ideal is to allow receive buffers to be
>> pre-posted on a per-stream basis, but to receive the
>> completions on a consolidated socket. In terms of a
>> VIA/IB/RDMA style interface, each stream has its own
>> Send and Receive Queues, but the  entire association
>> has a single Completion Queue.
>
> One catch is that this kind of schemes, event completion
> queue, normally align with file descriptor.  This means
> that after buffers are pre-posted to a socket, the
> completion event is delivered to the same socket.  The
> reason is simply that the framework is also used by
> other file descriptor, not just socket.  I agree that
> different implementations may have different architectures.
>
> Can people comment on whether the above file descriptor
> alignment is common on different platforms' event completion
> framework?  If this is true, then peeling off a stream from
> a socket fits what you mentioned above.
>
>> Personally, I believe there is more value in trying
>> to add that type of functionality to the API than in
>> running a classic synchronous socket for each stream.
>> However, I would agree that there are uses for both.
>> In particular, having to provide the target buffer
>> for a read *before* knowing what stream the next
>> message is for has always struck me as awkward.
>
>
> -- 
>
> 						K. Poon.
> 						[email-masked]
>
>