[sctp-dev] SCTP_EXPLICIT_COMPLETE

[Amir Eliaz]

Thanks for your answer, Chris.

So I now understand that the MessageInfo complete field is being ignored when invoking the native code.

Also, the workaround in http://web.archiveorange.com/archive/v/9eQBGG8xraoCAJy9ieIB  is not an option for us, since we cannot control the peers.

Do you think that increasing the buffer size (SO_SNDBUF) and disabling fragmentation (SCTP_DISABLE_FRAGMENTS) is an acceptable solution,

until the native API is finalized and the Java API updated accrodingly?

 

Regards,

--Amir

 

-----Original Message-----
From: Chris Hegarty [mailto:chris.hegarty at oracle.com] 
Sent: Wednesday, February 29, 2012 2:14 PM
To: Michal Lefler
Cc: Amir Eliaz; sctp-dev at openjdk.java.net; Gil Shafran
Subject: Re: [sctp-dev] SCTP_EXPLICIT_COMPLETE

 

Michal, Amir,

 

This issue came up before [1], and I believe the answer is still the same.

 

The issue is that lksctp still does not support the native SCTP_EXPLICIT_EOR socket option. Now that the socket extensions API has been finalized, RFC 6458 [1], I'm sure the various SCTP implementations will be revved support it. ( which should include support for SCTP_EXPLICIT_EOR).

 

There is a workaround described in [1], but I'm not sure if it would be acceptable to you.

 

Some background; SCTP_EXPLICIT_COMPLETE was originally added to the Java SCTP API so as not to have to have rev the API when the native support eventually came, hence it is marked as optional. I really felt that supporting large messages was important, but unfortunately the platform SCTP implementations haven't moved much over the past number of years. 

Hopefully now that the native API has been finalized there might be some renewed interest here.

 

-Chris.

 

[1]

http://mail.openjdk.java.net/pipermail/sctp-dev/2010-February/000179.html <http://mail.openjdk.java.net/pipermail/sctp-dev/2010-February/000179.html> 

[2] http://www.rfc-editor.org/rfc/rfc6458.txt <http://www.rfc-editor.org/rfc/rfc6458.txt> 

 

 

On 29/02/2012 11:12, Michal Lefler wrote:

> 

> 

> Amir Eliaz<amir.eliaz at traffixsystems.com <mailto:amir.eliaz at traffixsystems.com> >  wrote:

> 

> Hello Chris,

>     We tried testing on two different kernels:

> --  5.el6

> 2.6.32-131.0.15.el6.x86_64 #1 SMP Sat May 21 10:27:57 CDT 2011 x86_64 x86_64 x86_64 GNU/Linux

> Lksctp-tools version 1.0.10

> -- 3.el5

> 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

> lksctp-tools version 1.0.6

> 

> In both we get the exception "Protocol not available" when trying to access the socket option SCTP_EXPLICIT_COMPLETE from the Java API.

> 

> Regards,

> --Amir

> 

> -----Original Message-----

> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] <mailto:[mailto:chris.hegarty at oracle.com]> 

> Sent: Wednesday, February 29, 2012 12:14 PM

> To: Michal Lefler

> Cc: sctp-dev at openjdk.java.net <mailto:sctp-dev at openjdk.java.net> ; Gil Shafran; Amir Eliaz

> Subject: Re: [sctp-dev] (no subject)

> 

> Hi Michal,

> 

> What version of lksctp are you using? Also, what kernel?

> 

> -Chris

> 

> On 29/02/2012 09:15, Michal Lefler wrote:

>> Hi all.

>> We ran into the following problem.

>> Whenever we try to send sctp messages which are longer than 1024b the

>> messages are automatically splitted into two smaller messages.

>> The problem is that both messages are marked as "COMPLETED".

>> For that reason, the receiving side sees each long message as two

>> messages.

>> The first message is incomplete, while the second one is malformed.

>> We first suspected the MTU, but setting the MTU to a small value

>> resulted with a nice split (first message with an unset "COMPLETED",

>> and the second one is marked as "COMPLETED", as expected).

>> We tried to handle the "COMPLETED" flag manually, but trying to set

>> "SctpStandardSocketOption.SCTP_EXPLICIT_COMPLETE" to true caused a

>> "Protocol not supported" exception.

>> Any idea what the problem can be and how we can solve it?

>> We are using Java 1.6 u23, with the SCTP to Java 6 patch.

>> Thanks,

>> Michal.

>> 

> 

 

-- 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/sctp-dev/attachments/20120229/a1768c1d/attachment-0001.html