Subject: Re: sctp_peeloff()

From: Kacheong Poon <[email-masked]>
Date: Mon, 15 Dec 2003 23:53:16 -0800

Michael Tuexen wrote:

> Assume the you have 1 stream from A to B and 10 from B to A.
> Now you get a socket for receiving data on stream 5 at A. On
> what stream do you send data?

There is only one stream from A to B, so use that stream.
It is really a decision made by the app on how to arrange
the use of streams, and thus stream-socket...

> My point is not that the app does the wrong thing, but possibly it
> depends on the scheduling of the threads. Something which is out of scope
> of the transport...

It seems that system scheduling has very little to do
with the issue, unless the app itself tries to use
specific OS scheduling service to arrange different
scheduling for itself.  The worst case scenario you've
given is that a stream-socket will continue to read from
a specific stream, while other streams are "stuck"
therefore casuing a SCTP protocol issue as the TSN does
not move ahead.

Normally, this has nothing to do with system scheduling
as the scheduler should do the right thing.  The only
problem is that the app deliberately does not read.  This
is outside the control of the system.  If the app itself
tries to manipulate the scheduling, it'd better do the
right thing.

> If you can make sure that the app will receive data on ALL streams without
> delay, you have no problem. But how can you do this?

Only the app itself can make sure that it continues to
read.  The system cannot force an app to read.  But this
is fine and has nothing to do with the interface.  The
interface just makes sure that an app can receive from all
streams, whether the app chooses to read it is not the
interface's problem.  The stream-socket does not prevent
an app from receiving from all streams.

-- 

						K. Poon.
						[email-masked]