[sctp-dev] Basic Questions

[David Ryan]

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?  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.


>
>
>  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?


>
>
>  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.
>

That would be great!

Removed the rest to keep things focused!

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