Subject: Re: sctp_peeloff()

From: Caitlin Bestler <[email-masked]>
Date: Wed, 17 Dec 2003 13:38:18 -0600

On Dec 16, 2003, at 2:10 AM, Kacheong Poon wrote:

> Michael Tuexen wrote:
>
>>> Shouldn't this be the same as sending/receiving on a wrong
>>> stream id?  An error will be returned.  And I don't think
>>> an app which wants to use stream-socket will do the above.
>>> This does not require special handling anyway.
>>>
>> This means that such a socket is not bidirectional, but 
>> unidirectional.
>
> Why?  If an app picks stream number 1 to send one specific
> kind of data, both sides of an association can then use a
> stream-socket on stream number 1 to send and receive
> these messages.  Why isn't this bi-directional?  The
> "unidirectional" scenario above is similar to TCP's half
> closed case.  One side chooses to send only and the other
> side chooses to receive only.  But this does not make a TCP
> connection undirectional by nature.  It is the user which
> makes it undirectional.

There are two separate issues here:

a) specifying receive buffers in a stream dependent fashion

b) the order in which user messages are retrieved

Yes, avoiding rwnd exhaustion is ultimately the responsibility
of the application. After all, failure to issue *any* read
will result in the same problem. Thread specific routines
merely make it easier for the application to forget to have
the necessary read issued.

It also makes such a condition much less *obvious*. The most
likely error would be when a thread thought that a given
thread was idle, and hence did not issue a read. An border
condition or an error might come up where a message was
actually sent, resulting in pinning the rwnd down.

For that reason, I believe an interface that allows
the SCTP layer to deliver the completed message with
the lowest TSN is highly desirable and preferable to
an interface that lets the application cherry-pick
messages in arbitrary order.

I can think of two ways to do this:

a) pass a "buffer set" when reading, essentially
	allowing zero or more stream-specific buffers followed
	by one default buffer. The return would indicate which,
	if any, message had been delivered.

b) Requiring one socket to remain the "default" socket
    for the association, where streams that had not been
    "peeled off" would be delivered. When an application
    believed a stream to be idle, it would "close" that
    stream's socket, thereby returning control of that
    stream (or streams if bi-directional) to the association's
	default socket.