[sctp-dev] Basic Questions

[Christopher Hegarty - Sun Microsystems Ireland]

On 23/06/2009 12:53, David Ryan wrote:
> and more comments inline!
> 
> On Tue, Jun 23, 2009 at 7:42 PM, Christopher Hegarty - Sun Microsystems
> Ireland <Christopher.Hegarty at sun.com> wrote:
> 
>> comments inline...
>>
>>
>> On 23/06/2009 01:25, David Ryan wrote:
>>
>>>  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?
>>>
>> Sorry, not that I am aware of. You are now leading this effort ;-)
>>
> 
> Nothing like being on the bleeding edge. :)
> 
> 
>>  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.
>>>
>> 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 receive/processing.
>>
> 
> Thanks for the pointer, I haven't used the Selector APIs before (more
> naivety on my behalf).  Is there any information available from the selector
> to say what stream id will being received next from the channel?
No this is not possible. All the selector can tell you is that there is 
some data on the channel. It may be a message or a notification.

>  I've
> looked at the API and tried a couple of things but haven't found anything
> yet.
> 
> I was thinking that in the situation where you have multiple threads each
> waiting on a stream, it would be nice to block the thread and then when data
> was available you could notify the thread and it could receive the data
> directly into its buffer (this is in the non TLS/SSL situation). In effect
> this replicates the SctpChannel send/receive API but for individual
> streams.  This would obviously reduce buffer copies in the protocol stack.
> I'd still need to deal with the situation where a thread wasn't available to
> receive the data; most likely using a queue.
I'm not sure I fully understand your design, but the typical use of 
selectors is where you have a single thread block on the selector, when 
it fires (a channel is readable/writable), iterate over the
selected keys and hand off the ready channel for each key to another 
thread to do the actual work. In which cause you may want a pool of 
threads and buffers that can be reused.

>>  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.
>>
> 
> My understanding was that the SSLEngine is a kind of state machine.  If you
> had two streams on one association/channel trying to perform handshaking at
> the same time, the order of messages could get confused.  That was the main
> reason I was thinking that I'd require different SSLEngines on each stream.
> Is my understanding on this wrong?
SSLEngine is a state machine, but what I was suggesting is that you have 
a single SSL session for the channel. Handshaking takes place after the 
connection is made and then data is exchanged on any stream. As far as 
the SSLEngine is concerned it is simply decrypting data is does not 
concern itself with there the data comes from. You would need to keep 
the association between data and stream at the application level.

The difference between this design and what you suggested is that there 
is only one SSL session per channel where you were suggesting one SSL 
session per stream. Either should work, but I don't see that you need a 
session for each stream.

[snip]

-Chris.