[sctp-dev] Stream Count Overhead
ray.racine at gmail.com
Thu Oct 13 12:23:40 PDT 2011
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?
Thanks in advance,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sctp-dev