Subject: Re: sctp_peeloff()

From: Kacheong Poon <[email-masked]>
Date: Mon, 15 Dec 2003 04:50:43 -0800

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.

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

-- 

						K. Poon.
						[email-masked]