Java SSLSocketChannel/SSLSelector?

[Andi Mullaraj]

Inline my comments but putting this upfront so that it doesn't go unnoticed
for the occasional reader:

I was directed to this forum for discussing the merits and technicals
details of a possible SSLSelector/SSLSocketChannels. The level of
engagement seems to be very minimal though (I appreciate the effort of the
two members pitching their feedback). The best I have heard was "[..] make
SSL with Selectors easier, because right now it is very painful.  But this
approach is unlikely to succeed, at least in the JDK.", but without saying
why. Every Java developer I pitch this idea to, says the same thing "Are
you sure that SSLSelector/SSLSocketChannels are not in JDK? It cannot be
...". I proposed a concrete API but never got any feedback on that. I would
really appreciate if someone could tell me if this is the right path/forum
for discussing this.

Best,
--Andi Mullaraj


> I think nothing would prevent it
Great.

> but they chose to separate the SSL from the nio such that it was more
re-usable and opted to not spend the money/time on creating an SSLSelector
knowing people could program it on top.  (ie. the history).
That decision must have been made 15 years ago.

> Most stuff should be done outside the jdk anyways.  ie. look at logback
and how good it is and how the jdk logging which tried to copy log4j(and
failed) kinda sucks.
The reason I tackled this problem 2 years ago is that I could find no
third-party implementation of SSLSocketChannels with Selectors. I checked
how other applications dealt with that and felt the pain they must have
felt to get huge dependencies in, just to get a functionality as primordial
as this.

> The federation model in my opinion is better with libraries on top of nio
out in the wild.
The base java.nio.channels follows a federation model (SPI) and so could
this. Nothing would prevent a third party to plug in their desired
implementation (if there existed others, beyond the default)

> Coming back to why not do it?  There are so many things on their plate
already
I assume you are referring to the main/Oracle contributors being busy. I
certainly looks like that.

> and the problem of ssl over nio is solved so why spend money to make it
more perfect with so many other issues and things to work on that are most
likely more important.
This must be related to the pain threshold. I believe (and David also
mentioned) that working with SSLEngine is very painful. I mean, in order to
achieve a robust application with no edge cases especially when security
comes into play. This is not about making it perfect, it is about offering
something decent that, IMO, should have been there in first place.

Thanks,
--Andi


On Thu, Mar 7, 2019 at 7:50 AM Dean Hiller <dhiller at twitter.com> wrote:

> I think nothing would prevent it but they chose to separate the SSL from
> the nio such that it was more re-usable and opted to not spend the
> money/time on creating an SSLSelector knowing people could program it on
> top.  (ie. the history).
>
> Most stuff should be done outside the jdk anyways.  ie. look at logback
> and how good it is and how the jdk logging which tried to copy log4j(and
> failed) kinda sucks.
>
> The federation model in my opinion is better with libraries on top of nio
> out in the wild.
>
> Coming back to why not do it?  There are so many things on their plate
> already and the problem of ssl over nio is solved so why spend money to
> make it more perfect with so many other issues and things to work on that
> are most likely more important.
>
> Dean
>
>
> On Thu, Mar 7, 2019 at 12:46 AM Andi Mullaraj <andimullaraj at gmail.com>
> wrote:
>
>> 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
>>> I assume
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190308/0488ca3c/attachment.html>