[sctp-dev] FW: Platform support for SCTP ?

[Dennis Hjort]

Hi Christopher, 

So my guess was correct, and I have followed the development on
different platforms as well. 

The SCTP implementation we currently use is the JNI java implementation,
using lksctp, available at [1], on linux. This implementations is not
fully implemented, but so far we have, with help of the developer
maintaining the site, been able to get SCTP working for our needs. The
implementation only supports blocking channels, so we have had to make
several modifications to be able to handle this as we'd rather prefer
non-blocking implementation.  

The third party SCTP implementation you refer to might perhaps be [2] ?
I haven't had time testing it yet, but will do some testing in near
future just to see how robust it is at the current date. It has a
repository location at [3], and it seems as they keep working on it, as
the latest entry in the repository was 11/21/08 ! :-) 

The prototype you mention is of great interest to us, and it would be
great to begin using it. I have taken on me to be in charge of replace
the current implementation with the "native" java one when available,
and if that helps you it's just great. 

As I mentioned in my previous mail, we do use Linux primarly, but if I
get the windows implementation of SCTP working, perhaps I also could
help with contributing with windows support also. 

// Dennis

[1] http://i1.dk/JavaSCTP/
[2] http://www.co-conv.jp/en/product/sctpDrv/20080313/
[3] http://trac.sctp.jp/sctpDrv/trac.cgi/log/

-----Original Message-----
From: Christopher.Hegarty at Sun.COM [mailto:Christopher.Hegarty at Sun.COM]
Sent: den 28 november 2008 11:32
To: Dennis Hjort
Cc: sctp-dev at openjdk.java.net
Subject: Re: [sctp-dev] Platform support for SCTP ?

Hi Dennis,

Solaris has included support for SCTP since Solaris 10. The Linux 2.6
kernel has SCTP support built in, but to you need an extra library to
access user level SCTP socket extension functions. I have seen reference
to a third party windows SCTP implementation, but have no experience
with it and its name eludes me now.

Within the scope of this SCTP OpenJDK project I plan to develop a
prototype implementation for Solaris and Linux (using the lksctp
implementation). Of course, if someone wants to contribute a Windows
implementation then I am certainly not opposed to that.

The proposed draft API defines three new channel types, SctpChannel,
SctpServerChannel and SctpMutliChannel, all of which have static factory
open methods. These methods are specified to throw
UnsupportedOperationException if the SCTP protocol is not supported.

I have a prototype implementation for both Solaris and Linux that I hope
to be able to push the source soon. Would be be interested in using
this? What SCTP implementation are you currently using?

-Chris.

Dennis Hjort wrote:
> Hi,
> 
> I've been following this list and have a question regarding platform 
> support.
> 
> Currently, SCTP is supported in libraries on linux and solaris, but 
> what I know it has not yet support on windows. How does this impact 
> the java SCTP package ? Our application is currently running on Linux,

> but it would be wonderful to be able to run basictests and such on our

> development plattform also, which is Windows Vista.
> 
> With kind regards
> 
> // Dennis
> 
>       ******************************************************
>       This communication is confidential and intended solely for the
>       addressee(s). Any unauthorized review, use, disclosure or
>       distribution is prohibited. If you believe this message has been
>       sent to you in error, please notify the sender by replying to
this
>       transmission and delete the message without disclosing it. Thank
you.
> 
>       E-mail including attachments is susceptible to data corruption,
>       interception, unauthorized amendment, tampering and viruses, and
>       we only send and receive e-mails on the basis that we are not
>       liable for any such corruption, interception, amendment,
tampering
>       or viruses or any consequences thereof.
>