Subject: Re: sctp_peeloff()

From: Michael Tuexen <[email-masked]>
Date: Mon, 15 Dec 2003 17:18:00 +0100

Kacheong,

see my comments below.

Best regards
Michael

On Dec 15, 2003, at 1:50 PM, Kacheong Poon wrote:

> Randall Stewart (cisco) wrote:
>
>> 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...
>
> 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.
>>> 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....
>
> I think the first question to ask is really whether people
> want to use this feature.  If nobody wants that, we don't
> need to think more about.  That was my original question.
>
> 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.
> -- 
> 						K. Poon.
> 						[email-masked]