[sctp-dev] Stream Count Overhead

[Chris Hegarty]

Ray,

Thanks for reporting this issue.

I filed CR 7102655: "SctpStandardSocketOptions.InitMaxStreams.create 
throws IAE when passed 65536" for it. And hope to fix it soon.

The latest ( shipped with JDK7 ) SCTP API can be found at:
   http://download.oracle.com/javase/7/docs/jre/api/nio/sctp/spec/

( I admit, not the easiest to find! )

-Chris.

On 17/10/2011 20:19, Ray Racine wrote:
> 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
> <mailto: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
>
>
>
>
>
>
>