<div dir="ltr"><div dir="ltr">Hi David,<div><br></div><div>Thanks for following up. Addressing your questions and statements </div><div><br></div><div>1. Then your selector can only be used for SSL things.<br></div><div><br></div><div>The SSLSelector I am proposing may select on (plain) SocketChannels/ServerSocketChannels, (secure) SSLSocketChannels/SSLServerSocketChannels, and any mixture of them.</div><div><br></div><div>2. What if someone decides to take the exact same approach to solve some other higher-OSI-layer protocol decoding? Now you have to choose which kind of protocol you want your selector to support. </div><div><br></div><div>They create their own selector. I have hard time imagining one selector implementation being able to support various protocols at once. In the current discussion (and if one day this or a similar implementation makes it into jdk), the selector provider will know how to create (plain) SocketChannels as well as (secure) SSLSocketChannels.</div><div><br></div><div>3. Note that with a plain selector and plain sockets, you *need* a thread to support the event loop anyway, I mean it has to run somewhere.</div><div><br></div><div>I don't have enough knowledge here, but I am thinking it will depend on the OS ... if the OS provides similar hooks, then I'd say no other threads are needed -- the thread selecting would be entering a wait() until some notifier wakes it up ... not vital to the SSL part though.</div><div><br></div><div>4. And with SSL, you also need an extra thread or thread pool to handle SSL authentication tasks, no matter whether you make a subclass of Selector.</div><div><br></div><div>True. Resisting the temptation to get into implementation details, I would say it is the SSLSocketChannel that needs the thread pool (since the calls to select() should not deal with any crypto etc). In that case the user can bring its own thread pool (or executor), or use a default one shared by all channels of that selector provider, depending on their needs.<br></div><div><br></div><div>Best,</div><div>--Andi</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 15, 2019 at 4:56 AM David Lloyd <<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.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">Then your selector can only be used for SSL things. What if someone<br>
decides to take the exact same approach to solve some other<br>
higher-OSI-layer protocol decoding? Now you have to choose which kind<br>
of protocol you want your selector to support. Note that with a plain<br>
selector and plain sockets, you *need* a thread to support the event<br>
loop anyway, I mean it has to run somewhere. And with SSL, you also<br>
need an extra thread or thread pool to handle SSL authentication<br>
tasks, no matter whether you make a subclass of Selector.<br>
<br>
On Fri, Feb 15, 2019 at 2:35 AM Andi Mullaraj <<a href="mailto:andimullaraj@gmail.com" target="_blank">andimullaraj@gmail.com</a>> wrote:<br>
><br>
> Hi Dean,<br>
><br>
> 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 ...<br>
><br>
> 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" rel="noreferrer" 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:<br>
><br>
> 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:<br>
><br>
> Selector selector = Selector.open();<br>
> SocketChannel socketChannel = SocketChannel.open();<br>
> socketChannel.register(selector, SelectionKey.OP_READ);<br>
><br>
> while(true) {<br>
> selector.select();<br>
> for (SocketChannel sc : selector.selectedKeys() {<br>
> sc.read(...)<br>
> }<br>
> }<br>
><br>
> with:<br>
><br>
> Selector selector = SSLSelector.open(); // notice the SSL<br>
> SocketChannel socketChannel = SSLSocketChannel.open(); // notice the SSL<br>
> socketChannel.register(selector, SelectionKey.OP_READ);<br>
><br>
> while(true) {<br>
> selector.select();<br>
> for (SocketChannel sc : selector.selectedKeys() {<br>
> sc.read(...)<br>
> }<br>
> }<br>
><br>
> 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?<br>
><br>
> 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.<br>
><br>
> Thanks in advance,<br>
> --Andi<br>
><br>
><br>
> On Wed, Feb 13, 2019 at 8:22 AM Dean Hiller <<a href="mailto:dhiller@twitter.com" target="_blank">dhiller@twitter.com</a>> wrote:<br>
>><br>
>> I would highly suggest implementing your own for a much better understanding.<br>
>><br>
>> I did implement something like what you want and in so doing realized I like their decision. ie. See the heirarchy here<br>
>> <a href="https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2/src/main/java/org/webpieces/nio/api/channels" rel="noreferrer" target="_blank">https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2/src/main/java/org/webpieces/nio/api/channels</a><br>
>><br>
>> The TCPChannel could be SSL or not SSL as there are two implementations.<br>
>><br>
>> If you do want an implementation that does what you want though, this library does exactly that<br>
>> <a href="https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2" rel="noreferrer" target="_blank">https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2</a><br>
>><br>
>> which is used in the webpieces webserver<br>
>> <a href="https://github.com/deanhiller/webpieces" rel="noreferrer" target="_blank">https://github.com/deanhiller/webpieces</a><br>
>><br>
>> That nio library is standalone even though it is in the webpieces repo. I mean, every component in webpieces is another stand-alone piece.<br>
>><br>
>> 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).<br>
>><br>
>> later,<br>
>> Dean<br>
>><br>
>><br>
>><br>
>><br>
>> 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>
>>><br>
>>> 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>
<br>
<br>
<br>
-- <br>
- DML<br>
</blockquote></div>
</div>