Subject: Re: sctp_peeloff()

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 15 Dec 2003 06:32:02 -0600

Kacheong Poon wrote:

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

I think what Michael means here (correct me if I am wrong) is that
it is possible for one side to have 10 streams going towards the
peer and the other to have 1. So how do we handle this situation
i.e. I peel off stream 8 into a socket. Now stream 8 on one side
can send but NOT recieve. Stream 8 on the other side can receive
but NOT send...

Is this what you meant Michael?

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

But do we code things assuming the app will always do the
right thing? I think this is the fundamental question that
is being asked....

R

-- 
Randall R. Stewart
ITD - Transport Technologies
815-477-2127(o) or 815-342-4222(c)