[sctp-dev] Basic Questions

[David Ryan]

Hi Chris,

Sorry, I forgot SCTP_DISABLE_FRAGMENTS was not supported on Solaris.
> However, messages are fragmented by default. I added this option to ensure
> that fragmentation was possible on platforms where it was not the default.


I was surprised that quite a few of the options were not supported.  I guess
this means that for now I'll have to rely on what Solaris currently provides
and keep things simple (which is probably a good thing).


> The main motivation behind this was to support TLS/SSL over SCTP, see
> http://tools.ietf.org/html/rfc3436.
>

I found RFC3436 last week and have started to explore  TLS/SSL over SCTP.
I've got hold of the SSLEngineSimpleDemo and started to explore how best to
implement this over the SCTP interface.  Has anyone in Sun has already done
this?

>From initial investigations there's two fundamental design issues I'm
assuming.

The first is that SctpChannel.receive call does not allow filtering on
specific streams, so all data will need to be received by a single thread.
The second is that this will require separate SSLEngine objects for each
bi-directional stream.  Also, if each secure stream is to be presented as
different objects to the application it puts specific requirements on how
that is done.  The application will need to either register a call back that
can be called when data arrives for that stream, or a queue will need to be
used.  In either case a separate thread will need to receive all data from
the SctpChannel and decide if that data needs to be passed to a specific
SSLEngine instance or to an application callback/queue.

A related issue is that I haven't worked out how an SSLEngine can be
initiated with a session id of another SSLEngine to allow the abreviated
handshake as specified in RFC3436.

These aren't really SCTP specific questions I know, but thought you might be
interested in how the API will be used.  If/when I get some example code
running I'll post it here.  I'm attempting to build a secure daytime server
based on your example as a starting point.


> Another thing I noticed was that InvalidStreamException is an undeclared
>> exception.  It would be nice if this extended from IOException and could be
>> caught in the declared catch block.
>>
> InvalidStreamException is a RuntimeException (more specifically an
> IllegalArgumentException) and as such is not required to be caught. It is
> listed in the list of exceptions thrown by send, but not declared in the
> method description so you are not required to provide a catch block. Does
> this make sense or answer you question?
>

Yes and No. :)  I realised it was a RuntimeException.  I was really
questioning if this is the right design.  I can imagine that getting this
parameter wrong could be quite easy to do which would create a bug that
could easily slip through testing.  If it extended IOException the developer
is more likely to have code to handle IOExceptions already and the
consequence wouldn't be as bad.  Just a thought.


> I would personally leave it to SCTP to provide the message framing. I don't
> see any issues with allowing SCTP do the framing unless you require very
> large messages that the platform does not support.


Yes, I think this line of questions was showing my naivety of SCTP framing.
I went back and reviewed some of the SCTP introduction web sites and think I
have a better understanding now.

Please let me know your comments. Have I answers some of your questions or
> just confused things more? ;-)


Your comments have been really helpful!

Thanks,
David.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/sctp-dev/attachments/20090623/ac0f7f0e/attachment.html