From jason.kania at genband.com Fri Oct 7 08:36:00 2011 From: jason.kania at genband.com (Jason Kania) Date: Fri, 7 Oct 2011 15:36:00 +0000 Subject: [sctp-dev] Undefined symbol problems in libsctp.so running with java 1.6 Message-ID: <4A62469B6AD0314586E6173A7A8D74918C7C05FE@gbplmail03.genband.com> Hello, For RHEL 5 linux with kernel 2.6.18-92.1.22.el5, I downloaded the latest JDK 7 source and libsctp.so library. I am attempting to use the code modified for java 1.6, but I am encountering the following problem: > java -Xbootclasspath/a:sctp6.jar -classpath app.jar TestSCTP Exception in thread "main" java.lang.UnsupportedOperationException: /usr/java/jre1.6.0_12/lib/i386/libsctp.so: undefined symbol: sctp_getladdrs at sun.nio.ch.SctpNet.socket0(Native Method) at sun.nio.ch.SctpNet.socket(SctpNet.java:82) at sun.nio.ch.SctpChannelImpl.(SctpChannelImpl.java:131) at com.sun.nio.sctp.SctpChannel.open(SctpChannel.java:165) at TestSCTP.main(TestSCTP.java:4) app.jar is simply a jar to hold the TestSCTP.class file. The problem is the same when I use the libsctp.so file from the SCTP on 1.6 instruction page http://openjdk.java.net/projects/sctp/html/sctp6.html >From the error output, the library is definitely being found. When I use the nm command to list what symbols are in the library, I get the following name with "nio_" prefix instead: > nm /usr/java/jre1.6.0_12/lib/i386/libsctp.so ... nio_sctp_getladdrs ... The ldd output looks as follows: > ldd /usr/java/jre1.6.0_12/lib/i386/libsctp.so linux-gate.so.1 => (0xffffe000) libnio.so => /usr/java/jre1.6.0_12/lib/i386/libnio.so (0xf7f58000) libnet.so => /usr/java/jre1.6.0_12/lib/i386/libnet.so (0xf7f44000) libpthread.so.0 => /lib/libpthread.so.0 (0xf7f27000) libdl.so.2 => /lib/libdl.so.2 (0xf7f23000) libjava.so => /usr/java/jre1.6.0_12/lib/i386/libjava.so (0xf7efd000) libjvm.so => not found libc.so.6 => /lib/libc.so.6 (0xf7dba000) libnsl.so.1 => /lib/libnsl.so.1 (0xf7da3000) /lib/ld-linux.so.2 (0xf7f66000) libjvm.so => not found libjvm.so => not found libverify.so => /usr/java/jre1.6.0_12/lib/i386/libverify.so (0xf7d96000) libjvm.so => not found Permissions on the file and directories are all 755 The libsctp.jar library is included on the JVM command line as follows: Any suggestions on a direction for resolving this? Thanks for any help, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/sctp-dev/attachments/20111007/008db4fc/attachment.html From chris.hegarty at oracle.com Fri Oct 7 10:43:50 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 07 Oct 2011 18:43:50 +0100 Subject: [sctp-dev] Undefined symbol problems in libsctp.so running with java 1.6 In-Reply-To: <4A62469B6AD0314586E6173A7A8D74918C7C05FE@gbplmail03.genband.com> References: <4A62469B6AD0314586E6173A7A8D74918C7C05FE@gbplmail03.genband.com> Message-ID: <4E8F3A56.3090201@oracle.com> Jason, This exception would appear to indicate a problem trying to locate sctp_getladdrs in the lksctp socket exceptions library, /usr/lib/libsctp.so. Yes poor naming, I know. The lksctp socket exceptions library has the same name as the internal JDK JNI library! Can you try looking at the output of: nm /usr/lib/libsctp.so objdump -T /usr/lib/libsctp.so -Chris. On 10/ 7/11 04:36 PM, Jason Kania wrote: > Hello, > > For RHEL 5 linux with kernel 2.6.18-92.1.22.el5, I downloaded the latest > JDK 7 source and libsctp.so library. I am attempting to use the code > modified for java 1.6, but I am encountering the following problem: > > > java -Xbootclasspath/a:sctp6.jar -classpath app.jar TestSCTP > > Exception in thread "main" java.lang.UnsupportedOperationException: > /usr/java/jre1.6.0_12/lib/i386/libsctp.so: undefined symbol: sctp_getladdrs > > at sun.nio.ch.SctpNet.socket0(Native Method) > > at sun.nio.ch.SctpNet.socket(SctpNet.java:82) > > at sun.nio.ch.SctpChannelImpl.(SctpChannelImpl.java:131) > > at com.sun.nio.sctp.SctpChannel.open(SctpChannel.java:165) > > at TestSCTP.main(TestSCTP.java:4) > > app.jar is simply a jar to hold the TestSCTP.class file. > > The problem is the same when I use the libsctp.so file from the SCTP on > 1.6 instruction page > > http://openjdk.java.net/projects/sctp/html/sctp6.html > > From the error output, the library is definitely being found. > > When I use the nm command to list what symbols are in the library, I get > the following name with ?nio_? prefix instead: > > > nm /usr/java/jre1.6.0_12/lib/i386/libsctp.so > > ? > > nio_sctp_getladdrs > > ? > > The ldd output looks as follows: > > > ldd /usr/java/jre1.6.0_12/lib/i386/libsctp.so > > linux-gate.so.1 => (0xffffe000) > > libnio.so => /usr/java/jre1.6.0_12/lib/i386/libnio.so (0xf7f58000) > > libnet.so => /usr/java/jre1.6.0_12/lib/i386/libnet.so (0xf7f44000) > > libpthread.so.0 => /lib/libpthread.so.0 (0xf7f27000) > > libdl.so.2 => /lib/libdl.so.2 (0xf7f23000) > > libjava.so => /usr/java/jre1.6.0_12/lib/i386/libjava.so (0xf7efd000) > > libjvm.so => not found > > libc.so.6 => /lib/libc.so.6 (0xf7dba000) > > libnsl.so.1 => /lib/libnsl.so.1 (0xf7da3000) > > /lib/ld-linux.so.2 (0xf7f66000) > > libjvm.so => not found > > libjvm.so => not found > > libverify.so => /usr/java/jre1.6.0_12/lib/i386/libverify.so (0xf7d96000) > > libjvm.so => not found > > Permissions on the file and directories are all 755 > > The libsctp.jar library is included on the JVM command line as follows: > > Any suggestions on a direction for resolving this? > > > Thanks for any help, > > Jason > From chris.hegarty at oracle.com Fri Oct 7 10:47:45 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 07 Oct 2011 18:47:45 +0100 Subject: [sctp-dev] Undefined symbol problems in libsctp.so running with java 1.6 In-Reply-To: <4E8F3A56.3090201@oracle.com> References: <4A62469B6AD0314586E6173A7A8D74918C7C05FE@gbplmail03.genband.com> <4E8F3A56.3090201@oracle.com> Message-ID: <4E8F3B41.6030302@oracle.com> OH OH OH Stop. I just noticed this after clicking send. The JDK JNI libsctp.so library needs to load /usr/lib/libsctp.so, to locate some extension functions. It would appear that JDK JNI libsctp.so is finding itself rather than /usr/lib/libsctp.so. There must be an issue with your LD_LIBRARY_PATH. Can you check this? -Chris. On 10/ 7/11 06:43 PM, Chris Hegarty wrote: > Jason, > > This exception would appear to indicate a problem trying to locate > sctp_getladdrs in the lksctp socket exceptions library, > /usr/lib/libsctp.so. Yes poor naming, I know. The lksctp socket > exceptions library has the same name as the internal JDK JNI library! > > Can you try looking at the output of: > nm /usr/lib/libsctp.so > objdump -T /usr/lib/libsctp.so > > -Chris. > > > On 10/ 7/11 04:36 PM, Jason Kania wrote: >> Hello, >> >> For RHEL 5 linux with kernel 2.6.18-92.1.22.el5, I downloaded the latest >> JDK 7 source and libsctp.so library. I am attempting to use the code >> modified for java 1.6, but I am encountering the following problem: >> >> > java -Xbootclasspath/a:sctp6.jar -classpath app.jar TestSCTP >> >> Exception in thread "main" java.lang.UnsupportedOperationException: >> /usr/java/jre1.6.0_12/lib/i386/libsctp.so: undefined symbol: >> sctp_getladdrs >> >> at sun.nio.ch.SctpNet.socket0(Native Method) >> >> at sun.nio.ch.SctpNet.socket(SctpNet.java:82) >> >> at sun.nio.ch.SctpChannelImpl.(SctpChannelImpl.java:131) >> >> at com.sun.nio.sctp.SctpChannel.open(SctpChannel.java:165) >> >> at TestSCTP.main(TestSCTP.java:4) >> >> app.jar is simply a jar to hold the TestSCTP.class file. >> >> The problem is the same when I use the libsctp.so file from the SCTP on >> 1.6 instruction page >> >> http://openjdk.java.net/projects/sctp/html/sctp6.html >> >> From the error output, the library is definitely being found. >> >> When I use the nm command to list what symbols are in the library, I get >> the following name with ?nio_? prefix instead: >> >> > nm /usr/java/jre1.6.0_12/lib/i386/libsctp.so >> >> ? >> >> nio_sctp_getladdrs >> >> ? >> >> The ldd output looks as follows: >> >> > ldd /usr/java/jre1.6.0_12/lib/i386/libsctp.so >> >> linux-gate.so.1 => (0xffffe000) >> >> libnio.so => /usr/java/jre1.6.0_12/lib/i386/libnio.so (0xf7f58000) >> >> libnet.so => /usr/java/jre1.6.0_12/lib/i386/libnet.so (0xf7f44000) >> >> libpthread.so.0 => /lib/libpthread.so.0 (0xf7f27000) >> >> libdl.so.2 => /lib/libdl.so.2 (0xf7f23000) >> >> libjava.so => /usr/java/jre1.6.0_12/lib/i386/libjava.so (0xf7efd000) >> >> libjvm.so => not found >> >> libc.so.6 => /lib/libc.so.6 (0xf7dba000) >> >> libnsl.so.1 => /lib/libnsl.so.1 (0xf7da3000) >> >> /lib/ld-linux.so.2 (0xf7f66000) >> >> libjvm.so => not found >> >> libjvm.so => not found >> >> libverify.so => /usr/java/jre1.6.0_12/lib/i386/libverify.so (0xf7d96000) >> >> libjvm.so => not found >> >> Permissions on the file and directories are all 755 >> >> The libsctp.jar library is included on the JVM command line as follows: >> >> Any suggestions on a direction for resolving this? >> >> >> Thanks for any help, >> >> Jason >> From jason.kania at genband.com Fri Oct 7 14:08:38 2011 From: jason.kania at genband.com (Jason Kania) Date: Fri, 7 Oct 2011 21:08:38 +0000 Subject: [sctp-dev] Undefined symbol problems in libsctp.so running with java 1.6 In-Reply-To: <4E8F3B41.6030302@oracle.com> References: <4A62469B6AD0314586E6173A7A8D74918C7C05FE@gbplmail03.genband.com> <4E8F3A56.3090201@oracle.com> <4E8F3B41.6030302@oracle.com> Message-ID: <4A62469B6AD0314586E6173A7A8D74918C7C070C@gbplmail03.genband.com> Thanks very much! You were correct with both messages. For others that may hit this issue, I thought I would respond to the group. The problem that produced the error was: 1) the lksctp-tools package was not on the server (I didn't know it was required) 2) the lksctp-tools package contains a libsctp.so library that the the openJDK SCTP libsctp.so library is seeking 3) the LD_LIBRARY_PATH on the server included the path to the libsctp.so from the openJDK sctp implementation The result was the odd library loader message that seemed to indicate that the library could not find symbols within itself. Jason -----Original Message----- From: Chris Hegarty To: Jason Cc: sctp-dev at openjdk.java.net Subject: Re: [sctp-dev] Undefined symbol problems in libsctp.so running with java 1.6 OH OH OH Stop. I just noticed this after clicking send. The JDK JNI libsctp.so library needs to load /usr/lib/libsctp.so, to locate some extension functions. It would appear that JDK JNI libsctp.so is finding itself rather than /usr/lib/libsctp.so. There must be an issue with your LD_LIBRARY_PATH. Can you check this? -Chris. On 10/ 7/11 06:43 PM, Chris Hegarty wrote: > Jason, > > This exception would appear to indicate a problem trying to locate > sctp_getladdrs in the lksctp socket exceptions library, > /usr/lib/libsctp.so. Yes poor naming, I know. The lksctp socket > exceptions library has the same name as the internal JDK JNI library! > > Can you try looking at the output of: > nm /usr/lib/libsctp.so > objdump -T /usr/lib/libsctp.so > > -Chris. > > > On 10/ 7/11 04:36 PM, Jason Kania wrote: >> Hello, >> >> For RHEL 5 linux with kernel 2.6.18-92.1.22.el5, I downloaded the >> latest JDK 7 source and libsctp.so library. I am attempting to use >> the code modified for java 1.6, but I am encountering the following problem: >> >> > java -Xbootclasspath/a:sctp6.jar -classpath app.jar TestSCTP >> >> Exception in thread "main" java.lang.UnsupportedOperationException: >> /usr/java/jre1.6.0_12/lib/i386/libsctp.so: undefined symbol: >> sctp_getladdrs >> >> at sun.nio.ch.SctpNet.socket0(Native Method) >> >> at sun.nio.ch.SctpNet.socket(SctpNet.java:82) >> >> at sun.nio.ch.SctpChannelImpl.(SctpChannelImpl.java:131) >> >> at com.sun.nio.sctp.SctpChannel.open(SctpChannel.java:165) >> >> at TestSCTP.main(TestSCTP.java:4) >> >> app.jar is simply a jar to hold the TestSCTP.class file. >> >> The problem is the same when I use the libsctp.so file from the SCTP >> on >> 1.6 instruction page >> >> http://openjdk.java.net/projects/sctp/html/sctp6.html >> >> From the error output, the library is definitely being found. >> >> When I use the nm command to list what symbols are in the library, I >> get the following name with "nio_" prefix instead: >> >> > nm /usr/java/jre1.6.0_12/lib/i386/libsctp.so >> >> ... >> >> nio_sctp_getladdrs >> >> ... >> >> The ldd output looks as follows: >> >> > ldd /usr/java/jre1.6.0_12/lib/i386/libsctp.so >> >> linux-gate.so.1 => (0xffffe000) >> >> libnio.so => /usr/java/jre1.6.0_12/lib/i386/libnio.so (0xf7f58000) >> >> libnet.so => /usr/java/jre1.6.0_12/lib/i386/libnet.so (0xf7f44000) >> >> libpthread.so.0 => /lib/libpthread.so.0 (0xf7f27000) >> >> libdl.so.2 => /lib/libdl.so.2 (0xf7f23000) >> >> libjava.so => /usr/java/jre1.6.0_12/lib/i386/libjava.so (0xf7efd000) >> >> libjvm.so => not found >> >> libc.so.6 => /lib/libc.so.6 (0xf7dba000) >> >> libnsl.so.1 => /lib/libnsl.so.1 (0xf7da3000) >> >> /lib/ld-linux.so.2 (0xf7f66000) >> >> libjvm.so => not found >> >> libjvm.so => not found >> >> libverify.so => /usr/java/jre1.6.0_12/lib/i386/libverify.so >> (0xf7d96000) >> >> libjvm.so => not found >> >> Permissions on the file and directories are all 755 >> >> The libsctp.jar library is included on the JVM command line as follows: >> >> Any suggestions on a direction for resolving this? >> >> >> Thanks for any help, >> >> Jason >> From ray.racine at gmail.com Thu Oct 13 12:23:40 2011 From: ray.racine at gmail.com (Ray Racine) Date: Thu, 13 Oct 2011 15:23:40 -0400 Subject: [sctp-dev] Stream Count Overhead Message-ID: 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 From chris.hegarty at oracle.com Mon Oct 17 10:07:32 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 17 Oct 2011 18:07:32 +0100 Subject: [sctp-dev] Stream Count Overhead In-Reply-To: References: Message-ID: <4E9C60D4.8090108@oracle.com> 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 > > > > > > From ray.racine at gmail.com Mon Oct 17 12:19:30 2011 From: ray.racine at gmail.com (Ray Racine) Date: Mon, 17 Oct 2011 15:19:30 -0400 Subject: [sctp-dev] Stream Count Overhead In-Reply-To: <4E9C60D4.8090108@oracle.com> References: <4E9C60D4.8090108@oracle.com> Message-ID: 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 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 From chris.hegarty at oracle.com Wed Oct 19 06:06:18 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 19 Oct 2011 14:06:18 +0100 Subject: [sctp-dev] Stream Count Overhead In-Reply-To: References: <4E9C60D4.8090108@oracle.com> Message-ID: <4E9ECB4A.8030002@oracle.com> 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 > 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 > > > > > > >