[sctp-dev] Stream Count Overhead

[Ray Racine]

Chris, Thanks for the reply.

So far, on a basic connect, no discernible timing difference with a single
connection with 65K of messages on stream 0 vs one message per 65K of
streams.  Not sure which way approach I'll go with.  FWIW, I already code in
use which uses SCTP for intra-cluster communication (Paxos msgs).

One thing I did notice, and I don't know if I'm looking at the absolute
latest Javadoc, is a potential off by 1 issue.  The SCTP Javadoc[1] seems to
indicate 65536 is a valid max streams value.  However on both on the
clientsocket.open (...) and listener.setOption (STCP_INIT_MAXSTREAMS, ...)
using 65536 results in an exception.  65536 - 1 works fine.

[1]
http://openjdk.java.net/projects/sctp/javadoc/com/sun/nio/sctp/SctpChannel.html#open(java.net.SocketAddress,
int, int)

-Ray.

On Mon, Oct 17, 2011 at 1:07 PM, Chris Hegarty <chris.hegarty at oracle.com>wrote:

> Hi Ray,
>
> I am not aware of any additional overhead of using such a number of
> streams, at least not by the Java implementation.
>
> There may be a small accountancy overhead in the native kernel SCTP
> implementation, but it shouldn't be much. The Java implementation (built on
> top of the kernel impl) adds very little too. That said, I haven't
> experimented too much with large numbers of streams.
>
> Your project sounds interesting, and your experiences would be very
> welcome.
>
> -Chris.
>
>
> On 10/13/11 08:23 PM, Ray Racine wrote:
>
>> 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/20111017/3bfd57dc/attachment.html