Subject: Re: sctp_peeloff()

From: Kacheong Poon <[email-masked]>
Date: Sun, 14 Dec 2003 23:37:11 -0800

Michael Tuexen wrote:

>> I guess the point of having a socket for individual stream
>> is not related to what SCTP the protocol tries to do.  It
>> is more about how SCTP apps want to use the API.  So it
>> seems to me that the dicussion should be focused on whether
>> app programmers like to have such as interface.  Then the
>> second question is what kind of caveats this interface may
>> have.  Also note that the stream-socket can both send and
>> receive.  We should also consider the usefulness of having
>> stream-socket for sending.
>>
> Streams are not bidirectional. So how will you send?

Stream-socket is bidirectional means that it does the
obvious things.  A send() on it will cause the data to be
sent in the particular stream id.  Likewise, a receive()
on it will only receive data sent to the particular stream
id.

>> From the app's point of view, having different sockets for
>> different streams allow them to separate task handling easier.
>> It has nothing to do with how SCTP assigns TSNs.  The way an
>> app will see this is that it just needs to setup one association
>> but can have multiple data streams controlled individually.  This
>> is "like" opening multiple TCP connections.  Now whether SCTP can
>> provide identical semantics is another issue, we know that it
>> cannot because of the issue rasied.  But is it good enough so that
>> a well bahaved app can make use of it.  This is the question we
>> need to ask and answer.
> 
> This is my point: people want something like multiple TCP connections
> in one entity and might think about about an association with n streams
> in each direction such they can use them a bidirectional streams.
> But the BIG difference is that the TCP connections have separate
> buffer management and the receive buffer for the SCTP association
> is shared. So my answer to this is: It is not good enough.

See below.

>> What you described above is really in the SCTP protocol level.
>> What the stream scheduling I mentioned was about how an app could
>> schedule different threads in handling send/receive of different
>> streams.  I think they are separate issues.
> 
> This is really my point. When you write a multithreaded application
> you may want to block threads intentionally by using semaphores or
> other techniques. But the receive calls should be independent. And
> this is not the case.

If an app chooses to use this interface, it means that it will
make sure that it will not block forever such that only data
from one particular stream will be read.  The key here is that
will an app do the right thing? It seems that you are assuming
that an app will always do the wrong thing...

-- 

						K. Poon.
						[email-masked]