<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Dean,</div><div dir="ltr"><br></div><div dir="ltr">Thanks for sharing your experience. I took a look at your links and the model and implementation seems quite distant from the classic Selector/SelectableChannel though. You seem to allocate a thread per each Selector (which I agree is too much of a cost to pay), then fire actively [listener.selectorFired()] from that thread towards a SelectorListener ...</div><div dir="ltr"><br></div><div dir="ltr">We can come back to implementation details later, but first I would like to ask: any reason we cannot have an SSLSelector which extends the java.nio.channels.Selector, an SSLSocketChannel extending a java.nio.channels.SocketChannel, and so on? I believe we can, and in this doc <a href="https://github.com/rouplex/rouplex-niossl/blob/master/README.md" target="_blank">https://github.com/rouplex/rouplex-niossl/blob/master/README.md</a> I have provided the set of base classes that do just that. Since this is a dev group I am sharing a code snippet from the doc:</div><div dir="ltr"><br></div><div dir="ltr">As an example, an existing application which is using SocketChannel with a Selector for their communications, would be turned into a secure one, by simply replacing:</div></div><div><pre style="white-space:pre-wrap;box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px;margin-bottom:16px;margin-top:0px;background-color:rgb(246,248,250);border-radius:3px;line-height:1.45;overflow:auto;padding:16px;color:rgb(36,41,46)"><code style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px;background:transparent;border-radius:3px;margin:0px;padding:0px;border:0px;word-break:normal;display:inline;line-height:inherit;overflow:visible">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(...)
}
}
</code></pre><p style="box-sizing:border-box;margin-bottom:16px;margin-top:0px;color:rgb(36,41,46);font-family:-apple-system,system-ui,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:16px">with:</p><pre style="white-space:pre-wrap;box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px;margin-bottom:16px;margin-top:0px;background-color:rgb(246,248,250);border-radius:3px;line-height:1.45;overflow:auto;padding:16px;color:rgb(36,41,46)"><code style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px;background:transparent;border-radius:3px;margin:0px;padding:0px;border:0px;word-break:normal;display:inline;line-height:inherit;overflow:visible">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(...)
}
}</code></pre></div><div>How much cooler and easier than that can it get redressing your existing service using (performant) plain communications with (performant) secure ones? Or create a new (and secure) one using the exact knowledge you already have and never having to think SSLEngine again?</div><div><br></div><div>As I have already mentioned I have worked on such implementation but would like to first discuss with the group the merits and possible problems/shortcomings of adopting the inheritance model from the plain counterparts.</div><div><br></div><div>Thanks in advance,</div><div>--Andi</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 13, 2019 at 8:22 AM Dean Hiller <<a href="mailto:dhiller@twitter.com">dhiller@twitter.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">I would highly suggest implementing your own for a much better understanding.<div><br></div><div>I did implement something like what you want and in so doing realized I like their decision. ie. See the heirarchy here</div><div><a href="https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2/src/main/java/org/webpieces/nio/api/channels" target="_blank">https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2/src/main/java/org/webpieces/nio/api/channels</a><br></div><div><br></div><div><div>The TCPChannel could be SSL or not SSL as there are two implementations.</div><br class="gmail-m_3645673458550189932gmail-Apple-interchange-newline"></div><div>If you do want an implementation that does what you want though, this library does exactly that</div><div><a href="https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2" target="_blank">https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2</a><br></div><div><br></div><div>which is used in the webpieces webserver</div><div><div><a href="https://github.com/deanhiller/webpieces" target="_blank">https://github.com/deanhiller/webpieces</a></div></div><div><br></div><div>That nio library is standalone even though it is in the webpieces repo. I mean, every component in webpieces is another stand-alone piece.</div><div><br></div><div>The downside is the library owns a thread which typical java libraries avoid. ie. it has to have a thread to poll the selector and read from all the sockets to be fed to the thread pools, etc. I think that is the main reason they decided not to have this type of library. They prefer not to be running threads(which I agree, the jdk shouldn't).</div><div><br></div><div>later,</div><div>Dean</div><div><br></div><div><br></div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 12, 2019 at 7:54 PM Sean Mullan <<a href="mailto:sean.mullan@oracle.com" target="_blank">sean.mullan@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Andi,<br>
<br>
TLS/JSSE topics are best discussed on the security-dev alias, so I am <br>
copying that list for more discussion and -bcc-ing core-libs-dev.<br>
<br>
--Sean<br>
<br>
On 2/11/19 3:29 PM, Andi Mullaraj wrote:<br>
> Hi java-core community,<br>
> <br>
> I have been directed to this channel to discuss matters related to Java<br>
> performant ssl communications. Maybe this is a topic that has been<br>
> discussed in the past, in which case I would appreciate if someone pointed<br>
> me to that particular topic.<br>
> <br>
> Back in 2002 I personally applauded the java.nio.channels (jdk1.4) package,<br>
> realizing that there was no way to port this to the secure communications,<br>
> due to lack of a comparable implementation for SSL. But I thought it was<br>
> going to just be matter of time. A couple of years ago I had to go back<br>
> search for it, and was kind of surprised to find the following in<br>
> <a href="http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLENG" rel="noreferrer" target="_blank">http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLENG</a><br>
> :<br>
> <br>
> --- begin quote ---<br>
> Newcomers to the API may wonder "Why not just have an SSLSocketChannel<br>
> which extends java.nio.channels.SocketChannel?" There are two main reasons:<br>
> <br>
> 1. There were a lot of very difficult questions about what a<br>
> SSLSocketChannel should be, including its class hierarchy and how it should<br>
> interoperate with Selectors and other types of SocketChannels. Each<br>
> proposal brought up more questions than answers. It was noted that any new<br>
> API abstraction extended to work with SSL/TLS would require the same<br>
> significant analysis and could result in large and complex APIs.<br>
> 2. Any JSSE implementation of a new API would be free to choose the "best"<br>
> I/O & compute strategy, but hiding any of these details is inappropriate<br>
> for those applications needing full control. Any specific implementation<br>
> would be inappropriate for some application segment.<br>
> --- end quote ---<br>
> <br>
> It has been a while since this was stated, and I would really like to<br>
> revisit it. I personally believe that the question #1 has a quite natural<br>
> answer, while #2 should not really be a concern if we adhere to the spi<br>
> model where users can bring their own implementation if needed. I know<br>
> because I have also implemented it (but would like to discuss that in a<br>
> later stage, if it comes to it).<br>
> <br>
> The benefit of such implementation would be immense. Imagine many Java<br>
> services written with nio and which struggle to move to SSL due to the<br>
> great complexity of using SSLEngine (zookeeper service to name one), while<br>
> all they would need to do (if SSLSocketChannels were available) is to<br>
> instantiate an instance of SSLSocketChannel/SSLSelector when the security<br>
> is required and the rest would stay the same (as in case of plain<br>
> communication using SocketChannel/Selector). Another important use case is<br>
> the advent of IOT, where millions of devices, with relatively low<br>
> throughput would want to protect their communication via SSL.<br>
> <br>
> The ways I have seen the community deal with this are mainly:<br>
> <br>
> 1. Go through the pain of learning SSLEngine (and hope to get it right)<br>
> 2. Build their services around tested libraries (like Jetty, which handle<br>
> the SSL offload but don't resurface it in SocketChannel/Selector paradigm,<br>
> that also come with their huge set of dependencies, bringing in unavoidable<br>
> version collisions)<br>
> 3. Use proxies (nginx, ha) to deal with the high number of SSL connections<br>
> and divide the load by scaling horizontally in the back end (making for a<br>
> harder deployment model)<br>
> <br>
> We can make this a lot easier!<br>
> <br>
> Any feedback is greatly appreciated,<br>
> Best,<br>
> <br>
> Andi Mullaraj<br>
> <br>
</blockquote></div>
</blockquote></div>