Thanks for following up David,
You just made my day. Really. I have finally something concrete in front of
me that I can address.
In interest of keeping this discussion in focus, I will bypass the rest and
address a couple of key points from your response:
> 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.
Cut & pasting from a previous message of mine in this same thread, here is
the way a java.nio.channels loop works as of today (no SSL):
Selector selector = Selector.open();
SocketChannel socketChannel = SocketChannel.open();
socketChannel.register(selector, SelectionKey.OP_READ);
while(true) {
selector.select();
for (SocketChannel sc : selector.selectedKeys() {
sc.read(...)
}
}
and here it is how it works with my implementation (which I am considering
offering it to JDK):
Selector selector = SSLSelector.open(); // notice the SSL
SocketChannel socketChannel = SSLSocketChannel.open(); // notice the SSL
socketChannel.register(selector, SelectionKey.OP_READ);
while(true) {
selector.select();
for (SocketChannel sc : selector.selectedKeys() {
sc.read(...)
}
}
Adding the following block to show the same (and some) if it ever made it
to JDK -- is quite evident, but adding it here to avoid any possible
misunderstanding:
Selector selector = Selector.open(); // notice no SSL, but internally
the SelectorProvider pics the SSLSelector
SocketChannel socketChannel1 = SocketChannel.open(); // notice Plain
SocketChannel socketChannel2 = SSLSocketChannel.open(); // notice SSL
socketChannel1.register(selector, SelectionKey.OP_READ); // notice
mixture of channels
socketChannel2.register(selector, SelectionKey.OP_WRITE); // notice
mixture of channels
while(true) {
selector.select();
for (SocketChannel sc : selector.selectedKeys() {
if (sc.isReadable()) sc.read(...)
if (sc.isWritable()) sc.write(...)
}
}
So:
1. There is no special Selector (that the user sees), just the good old
Selector.
2. The user creates SSLSocketChannels (and possibly SocketChannels,
SSLServerSocketChannels, ServerSocketChannels) and registers them
altogether with the Selector.
What is ugly and smelly here? How much cleaner can we bridge today's world
and tomorrow's? At the end of the day, a developer wants to use the same
model, to achieve performant SSL communication the same way it used to with
non-SSL communication. Just like in the blocking world, an InputStream can
be obtained from a Socket or an SSLSocket, then it can be read upon in
indistinguishable manner.
> 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.
In light of the previous point, I couldn't disagree more. As it is
painfully clear, the proposed approach stays within the confines of nio,
and no duplication is needed (I also hate duplication).
I am commenting on the rest, but I believe this is nearly not as important
as the points above. Feel free to discard:
> 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.
Agreed. My answer has to be taken in the context of "... opted to not spend
the money/time on creating an SSLSelector knowing people could program it
on top"
> The correct abstraction you're looking for is not a Selector, it's an
"event loop".
The "event loop" or whatever pattern that can be chosen today will be
possible tomorrow with the proposed API. XNIO should be able to ingest this
right in, same way (I assume) it does with Selector/SocketChannel, and
without need to use SSLEngine to encrypt/decrypt SSL.
> 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).
Not to say I don't follow discussions, but why should I when I can develop
something myself, see it work perfectly, test it to work with hundreds of
thousands of SSL connections on a single host, handling 23GBPS of SSL
traffic on a 25GBPS network (75% usage over 48 CPUs)?
Thanks again,
--Andi
On Fri, Mar 8, 2019 at 6:21 PM David Lloyd <david.ll...@redhat.com> wrote:
> On Fri, Mar 8, 2019 at 4:17 PM Andi Mullaraj <andimulla...@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
>
