[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-sctp-dev
Subject:    [sctp-dev] Strange closing of SCTP channel
From:       chris.hegarty () oracle ! com (Chris Hegarty)
Date:       2011-11-18 14:50:31
Message-ID: 4EC670B7.1070701 () oracle ! com
[Download RAW message or body]

On 11/15/11 09:54 AM, Jens Carlberg wrote:
> Chris,
> 
> We have managed to narrow down the problem to the fact that the INIT message \
> contains 2 IP addresses for the client. When shutting down the extra interface, the \
> problem went away. This, of course, triggers new questions... :-)

Hmm... interesting.

> * How can we control what IP addresses the SCTP will send in the INIT message? For \
> our current testing we can shutdown the interface, but it is not a solution in the \
> long run.

You can use SctpChannel.bind/bindAddress/unbindAddress

> * The two machines have the same IP address on an interface; will this trigger the \
>                 behaviour we have seen?
> * We see the COMM_LOST after between 2 and 5 seconds. How come we see such \
> different times?

I'm afraid I can't answer these questions. The Java SCTP implementation 
is a wrapper on top of the Linux Kernel SCTP implementation. These 
issues sound more likely to be kernel issues rather that anything in Java.

Have you tried with lksctp-developers at lists.sourceforge.net?? These guys 
are responsible for the lksctp stack in the Linux kernel and are really 
helpful.

-Chris.

> 
> 
> ///Best regards, Jens Carlberg
> 
> -----Original Message-----
> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> Sent: den 14 november 2011 15:37
> To: Jens Carlberg
> Cc: sctp-dev at openjdk.java.net
> Subject: Re: [sctp-dev] Strange closing of SCTP channel
> 
> Jens,
> 
> Sorry, I haven't seen this strange type of behavior before. Is it possible for you \
> to test the client with the SCTP implementation from JDK7 in case this is some \
> strange issue with taking the implementation out of 7 and putting it in 6? 
> -Chris.
> 
> On 10/11/2011 14:02, Jens Carlberg wrote:
> > Hi!
> > I and a colleague are working with an application, working as SCTP
> > server. We're seeing a strange behaviour we fail to understand, where
> > the SCTP link closes on the server side when we are using a test
> > client, without any reason we can perceive. When used with a "real"
> > client, the link has no such problems. Also, the test client works
> > well when used over the loopback interface.
> > The sequence looks like this:
> > * The server starts and accepts incoming connections.
> > * The client starts and connects, getting a SCTP channel. We have
> > dumped the network traffic and can see the complete startup sequence
> > from INIT to COOKIE_ACK.
> > * The client sends a request (a telecom protocol using SCTP as
> > transport). The server sends a response. After this the link should
> > stay open, waiting for further communication.
> > * After a second or two, we can see in our application that SCTP
> > delivers a notification, a AssociationChangeNotification with COMM_LOST.
> > There is no packet corresponding to this in the network traffic dump
> > we have looked at.
> > * After about 30 seconds, the client sends a HEARTBEAT and gets an
> > ABORT back.
> > When using a "real" client or loopback interface, there is no
> > notification delivered and the link stays up. We have gotten a network
> > dump for the "real" client case, but not for the loopback interface.
> > We are using...
> > * Java 1.6.18 with the SCTP from Java 7.
> > * Linux 2.6.32.12 with a hight refresh rate (1000 Hz instead of 250)
> > * lksctp-tools-1.0.10-2.1 and lksctp-tools-devel-1.0.10-2.1 Under what
> > circumstances will a notification be generated? Can there be traffic
> > we doesn't see, since we only look for traffic to/from the client? Can
> > there be notification generated by other events?
> > We include the two network dumps we have collected.
> > 
> > ///Best regards,
> > 
> > line
> > 
> > *JENS CARLBERG **
> > Software Designer*
> > 
> > 
> > Ericsson AB
> > FU Radio System I&V, LI/EAB/FJZ/TE
> > Datalinjen 4
> > SE-58112 Link?ping, Sweden
> > Phone +46 107114141
> > SMS/MMS +46 761497941
> > jens.carlberg at ericsson.com
> > www.ericsson.com
> > 
> > 
> > 
> > Ericsson
> > 
> > 
> > 
> > 
> > This Communication is Confidential. We only send and receive email on
> > the basis of the terms set out at www.ericsson.com/email_disclaimer
> > <http://www.ericsson.com/email_disclaimer>
> > 


[prev in list] [next in list] [prev in thread] [next in thread]