Java SSLSocketChannel/SSLSelector?

[Andi Mullaraj]

Hi again,

> That implies multiple threads using 1 selector ...

It definitely looks like we are talking about different things. You seem to
be talking about *how to use a Selector and encrypt/decrypt ssl and do it
in an efficient way in order to build some server or so*. I am talking
about *providing an SSLSelector (which agreed, would be wrapping a Selector
and handle the encrypt/decrypt) of the same exact
API/Semantics/Functionality as a Selector*.

I agree the implementation is super complex, that's why I keep swerving
away from implementation details. I agree with you that there is no point
in using one Selector (either flavor) from a multitude of threads, but
(since I am on the provider side) in order to claim the SSLSelector is a
true reflection of a Selector I have to provide a way to make it work even
when callers perform concurrent select() operations from various threads
(which normally results in the locks being acquired in the order defined in
the documentation). So yes,the implementation is even more complex than you
actually describe it, but doable and very performant as well.

So, trying to swerve back to the API discussion, I will re ask my last
question in a different way:  If you have developed an application which
communicates in TCP using java.nio.channels package classes (one Selector,
multiple SocketChannel, one or more threads, doesn't matter), and you
wanted to enhance your application to be able to communicate over SSL, what
would stop you from using an SSLSelector with SSLSocketChannels (just
import them, pass the SSLContext during the SSLSocketChannelCreation,
recompile and done)? *Restating that the implementation is in pure Java,
with no extra threads for selection, with minimal cpu and memory impact
(only for SSL channels) over the current implementation. What would prevent
someone from using it?*

Thanks again,
--Andi



On Tue, Feb 19, 2019 at 8:18 AM Dean Hiller <dhiller at twitter.com> wrote:

> I am beginning to think we might be on different pages here. Someone from
>> outside the selector calls selector.select(), and all selector's
>> functionality is handled within the context of the calling thread. So where
>> is the need for the extra thread here? More specifically, in the
>> SSLSelector case, a call to its select, ends up usually to a call to its
>> inner selector.select(), always in the context of the calling thread ... so
>> same thing again. Why do you think another thread is necessary here (within
>> the selector itself)?
>>
>
> That implies multiple threads using 1 selector.  That can be very
> dangerous and prone to bugs.  Even with SSL, I would shy away from making
> something like that unless putting it behind some library/abstraction like
> netty, webpieces channelmanager or something.
>
> In fact, the performance of 1 thread that runs the selector who dishes the
> work to a threadpool immediately (N sockets to X threads) has been
> amazing!!!  *It was even better than multiple threads on a selector we
> found.* This was because that caused lots of contention with
> locks(slowing it down).  The contention depended on the application as some
> apps had more contention than others.  I would highly advise just sticking
> 1 thread on the selector dishing out to a thread pool which removed all
> contention to streamline the whole process for speed.
>
> THEN, if you do have a threadpool and an simple implementation that runs
> the data serially per socket in the threadpool(this is quite easy to do),
> you can do the decryption in the threadpool as well.  webpieces impl does
> this as well.
>
> just my 2 cents,
> later,
>
> Dean
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190306/929da8b6/attachment.htm>