Subject: Read from specific Stream id

From: "ROBERT MAGNUSSON" <[email-masked]>
Date: Tue, 09 Mar 2004 08:50:13 +0100

Hello ! 
We are planning to use SCTP in a project at Karlstad University Sweden  
and after reading the documentation about SCTP we came up with the  
following question: 
According to RFC 2960 section 10.1 G one may specify which stream to  
receive data on. We have looked at some specific implementations and  
found that not all of them include this feature. Are we missing some  
information about changes in the standard or is it possible that this  
feature simply isn't yet included in all implementations? 
Our interpretation of RFC 2960 is that this feature should be supported,  
is this correct?  
 
Greatful for answers 
Regards 
Tomas Nilsson and Robert Magnusson 
Karlstad University Sweden

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Tue, 09 Mar 2004 09:09:50 -0600

ROBERT MAGNUSSON wrote:
Robert:

You post made it to the list this time.. but it
was empty??

R

-- 
Randall R. Stewart
ITD - Transport Technologies
815-477-2127(o) or 815-342-5222(c)

---

From: Craig Rodrigues <[email-masked]>
Date: Tue, 9 Mar 2004 10:47:09 -0500

> You post made it to the list this time.. but it

It got through, it was just mangled by MIME somehow:

----- Forwarded message from ROBERT MAGNUSSON <[email-masked]> -----

Subject: Read from specific Stream id
To: [email-masked]
From: "ROBERT MAGNUSSON" <[email-masked]>
Date: Tue, 09 Mar 2004 08:50:13 +0100

Hello !

Greatful for answers
Regards

----- End forwarded message -----
 
-- 
Craig Rodrigues        Distributed Systems and Logistics, Office 6/325A
[email-masked]       BBN Technologies
(617) 873-4725         Cambridge, MA

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 9 Mar 2004 13:19:34 -0600

> Karlstad University Sweden

You are confusing buffering with association.  This was actually
discussed recently on the list.

Anyway, with the current sockets interface you need to have
a cross-stream dispatcher that supplies the buffer and accepts
messages before it dispatches the message for stream specific
processing.

This works very well if your application has an event/dispatch
architecture (where each stream is represented by an object rather
than by a thread).

Recently there was a thread discussing possible enhancements to
the API to allow buffers to be posted on a per-stream basis.
There may yet be a proposed based on this idea, but the critical
concern raised was the need to prevent thread-specific buffering
from becoming "blocking because one thread didn't supply a buffer".

I believe the consensus was that any new API feature should at
the minimum make it difficult for an application to accidentally
fail to provide a buffer for any one stream and thereby hold
up the entire association.

While I support that idea, you need to remember that *most*
applications do not need per-stream buffering. There is no
real attachment between the transaction buffer and the stream,
it is just a left-over relic from TCP-bound thinking. It is
a rare application that has a specific need to place messages
in specific buffers, because they are after all messages
rather than packets. Reassembly is already provided by SCTP.

Most applications will be able to apply the event/dispatch
model without stream-specific buffering. The server end will
more closely resemble a multi-session UDP server or a GUI
Program's Main Loop than a classic TCP server, however.

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Tue, 09 Mar 2004 15:11:30 -0600

Caitlin:

Excellent answer as always.. but one
point I want to make :->

>> feature simply isn't yet included in all implementations? 

A) 10.1 G is NOT part of the standard where MUST's and SHOULD's apply. It
    (as it states in the beginning of section 10) is a example API and 
no one
    is required to implement it has described.

B) Even in this "mythical section" (I actually had the word mythical in
     the drafts up until the very last :-D) it states that the stream id
     is an optional attribute...

R