[sctp-dev] Stream Count Overhead

[Ray Racine]

Need some guidance.

Intent is to use SCTP as the means to send ProtocolBuffer msgs in an asynch
request / response manner between internal systems in a datacenter.

Another option I looked at was possibly leveraging SPDY over TCP to frame
the protocolbuffer msgs.   But I'd be stuck with TCP head-of-line-blocking
and seems SCTP would be a much better way to go.

SPDY uses what it calls stream ids as basically a one time use request /
response identifier.  i.e. Send requests async on stream N, N+1, N+2, ...
(they really use even / odd but you get the idea).  So if you get a response
back on stream N+M you know that was the response for the N+M'd request.  IF
one were to replicate this behavior over SCTP and used a standard
STCPChannel connect/accept approach then the MAX IN/OUT streams are
negotiated at connection time.

In SPDY this approach is cost free.  I don't have an intuition for the
per-stream cost of a (JVM) SCTP connection.  Say I have a server with 100
SCTP client connections where each connection is negotiated at the maximum
permitted IN/OUT streams and where each stream is used once until rollover,
and then progress through the streams again.  (SPDY would require the
connection to be reestablished.)

Normally I wouldn't even think about going this route and would say set up 2
streams per SCTP connection, one for control msgs and one for data msgs.
 However, I did a google search for SCTP and SPDY and I actually found a
study by of SPDY over SCTP by a knowledgeable SCTP expert that appears to
have taken this approach.  Any substantive problem with maxing the streams
on a SCTP connection?

Advice?

Thanks in advance,

Ray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/sctp-dev/attachments/20111013/b3358cb5/attachment.html