Subject: Re: sctp_peeloff()

From: Kacheong Poon <[email-masked]>
Date: Tue, 16 Dec 2003 00:10:58 -0800

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.

>> But getting back to the above, a similar situation can be
>> said on mutex.  An app can cause dealock itself by using
>> mutex incorrectly.  All OSes still provide mutex because
>> of its usefulness.  So we need to answer the question of
>> the usefulness of the stream-socket first.
> 
> Mutexes are for dealing with race conditions and so on, so
> handling them incorrectly results in deadlocks. That is OK.
> stream-sockets are not for that, but to (mis)use the stream ID
> as a demulitplexer for an ULP. So having a deadlock is not
> within the scope of stream IDs, I think.

I guess I did not pick a good example.  The point I tried to
make was that any inappropriate use of a routine provided
by a system can cause problems.  And could you elaborate the
point about misusing the stream id as a demultiplexer?  Do
you mean to say that an SCTP app should never use stream id
as it is not designed to differentiate different flows in
an association?

-- 

						K. Poon.
						[email-masked]