Java SSLSocketChannel/SSLSelector?

[David Lloyd]

On Fri, Mar 8, 2019 at 4:17 PM Andi Mullaraj <andimullaraj at gmail.com> wrote:
>
> 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.

The answer is that selectors are for implementing event loops.  SSL is
a thing that applies to sockets.  Combining them doesn't make sense
from any rational engineering perspective.  Having a special Selector
type for SSL channels is weird, period.  It's ugly, it smells.  It
doesn't solve the problem in a clean way.  It's certainly not the
*best* solution.  And what other things will we then need special
Selector types for?  If the answer is "nothing", then why do we need a
special Selector subclass for SSL to begin with, instead of just using
Selector?

> Every Java developer I pitch this idea to, says the same thing "Are you sure that SSLSelector/SSLSocketChannels are not in JDK?"

All this says is that the Java developers you have talked to have (a)
never implemented non-blocking SSL (as evidenced by the fact that they
do not have any familiarity with the APIs) and (b) therefore do not
understand the complexities therein, or to put it more bluntly, they
have no idea what they're talking about.  I mean saying that Joe
Developer thinks some complex thing they've never looked at or
bothered to understand ought to be simple isn't really a great
argument for a lot of otherwise very busy people to drop everything to
review something that they know, based on their own expertise, isn't
really a workable solution to the problem.

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

This, for the record, has nothing to do with anything.  Some things
designed long ago are good; some are not good.  Age doesn't make ideas
go rotten.  These decisions were made for good reasons; the result may
not be perfect but it's not significantly worse now than in the 1.4
days.  The OS-level APIs that underpin Selector have not changed that
much either.

> > 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 correct abstraction you're looking for is not a Selector, it's an
"event loop".  It is possible to have an API based on Channels that is
ready-callback driven instead of Selector-driven, and such an API can
support SSL cleanly.  This is the basis of my XNIO project.  It is
only slightly higher level than Selector; the Channels are otherwise
largely similar.

Selector is just too low-level to abstract the concept neatly (see:
countless discussions about the difficulty of implementing the
lowest-level event loop in every network daemon software written in
the past 30 years).

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

What you're looking for is a better non-blocking approach to SSL, and
I too would love to see it.  If it ever comes to the JDK though, it
would have to come in the form of a JDK-level event loop abstraction,
with callback-driven channels that extend NIO.  I don't see that
happening unless it would be part of a long term plan to deprecate
NIO: the JDK folks hate needless duplication.  This seems unlikely.
But hey, maybe it's time for that idea to get its day.

-- 
- DML