[sctp-dev] Basic Questions
Christopher Hegarty - Sun Microsystems Ireland
Christopher.Hegarty at Sun.COM
Tue Jun 23 02:42:26 PDT 2009
On 23/06/2009 01:25, David Ryan wrote:
> 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
> 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
Sorry, not that I am aware of. You are now leading this effort ;-)
>>From initial investigations there's two fundamental design issues I'm
> 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.
Yes, only one thread can be receiving at any time, but the same thread
does not necessarily need to receive all the messages. You can use a
selector to determine if there is a message/notification available, and
then hand off the channel to a thread from a thread pool to do the
> The second is that this will require separate SSLEngine objects for each
> bi-directional stream.
Only if you want separate SSL sessions per stream. You could have a
single SSL session, that is one SSLEngine, per association/channel.
Therefore, all streams would use the same SSLEngine. You would need to
ensure that each message is read completely before a message on another
stream is received, this is the default behavior on Solaris.
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.
I'm not sure either. Let me see if I can find out.
> These aren't really SCTP specific questions I know, but thought you might be
> interested in how the API will be used.
Yes, very much so.
>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.
That would be great. I am very interested in how this works out. Please
keep me in the loop.
>> 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.
Yes, this is certainly true. Let me think about this.
>> 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!
More information about the sctp-dev