Then your selector can only be used for SSL things. 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. 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. 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.
On Fri, Feb 15, 2019 at 2:35 AM Andi Mullaraj <andimulla...@gmail.com> wrote: > > Hi Dean, > > 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 ... > > 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 > https://github.com/rouplex/rouplex-niossl/blob/master/README.md 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: > > 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: > > 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(...) > } > } > > with: > > 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(...) > } > } > > 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? > > 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. > > Thanks in advance, > --Andi > > > On Wed, Feb 13, 2019 at 8:22 AM Dean Hiller <dhil...@twitter.com> wrote: >> >> I would highly suggest implementing your own for a much better understanding. >> >> I did implement something like what you want and in so doing realized I like >> their decision. ie. See the heirarchy here >> https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2/src/main/java/org/webpieces/nio/api/channels >> >> The TCPChannel could be SSL or not SSL as there are two implementations. >> >> If you do want an implementation that does what you want though, this >> library does exactly that >> https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2 >> >> which is used in the webpieces webserver >> https://github.com/deanhiller/webpieces >> >> That nio library is standalone even though it is in the webpieces repo. I >> mean, every component in webpieces is another stand-alone piece. >> >> 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). >> >> later, >> Dean >> >> >> >> >> On Tue, Feb 12, 2019 at 7:54 PM Sean Mullan <sean.mul...@oracle.com> wrote: >>> >>> Hi Andi, >>> >>> TLS/JSSE topics are best discussed on the security-dev alias, so I am >>> copying that list for more discussion and -bcc-ing core-libs-dev. >>> >>> --Sean >>> >>> On 2/11/19 3:29 PM, Andi Mullaraj wrote: >>> > Hi java-core community, >>> > >>> > I have been directed to this channel to discuss matters related to Java >>> > performant ssl communications. Maybe this is a topic that has been >>> > discussed in the past, in which case I would appreciate if someone pointed >>> > me to that particular topic. >>> > >>> > Back in 2002 I personally applauded the java.nio.channels (jdk1.4) >>> > package, >>> > realizing that there was no way to port this to the secure communications, >>> > due to lack of a comparable implementation for SSL. But I thought it was >>> > going to just be matter of time. A couple of years ago I had to go back >>> > search for it, and was kind of surprised to find the following in >>> > http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLENG >>> > : >>> > >>> > --- begin quote --- >>> > Newcomers to the API may wonder "Why not just have an SSLSocketChannel >>> > which extends java.nio.channels.SocketChannel?" There are two main >>> > reasons: >>> > >>> > 1. There were a lot of very difficult questions about what a >>> > SSLSocketChannel should be, including its class hierarchy and how it >>> > should >>> > interoperate with Selectors and other types of SocketChannels. Each >>> > proposal brought up more questions than answers. It was noted that any new >>> > API abstraction extended to work with SSL/TLS would require the same >>> > significant analysis and could result in large and complex APIs. >>> > 2. Any JSSE implementation of a new API would be free to choose the "best" >>> > I/O & compute strategy, but hiding any of these details is inappropriate >>> > for those applications needing full control. Any specific implementation >>> > would be inappropriate for some application segment. >>> > --- end quote --- >>> > >>> > It has been a while since this was stated, and I would really like to >>> > revisit it. I personally believe that the question #1 has a quite natural >>> > answer, while #2 should not really be a concern if we adhere to the spi >>> > model where users can bring their own implementation if needed. I know >>> > because I have also implemented it (but would like to discuss that in a >>> > later stage, if it comes to it). >>> > >>> > The benefit of such implementation would be immense. Imagine many Java >>> > services written with nio and which struggle to move to SSL due to the >>> > great complexity of using SSLEngine (zookeeper service to name one), while >>> > all they would need to do (if SSLSocketChannels were available) is to >>> > instantiate an instance of SSLSocketChannel/SSLSelector when the security >>> > is required and the rest would stay the same (as in case of plain >>> > communication using SocketChannel/Selector). Another important use case >>> > is >>> > the advent of IOT, where millions of devices, with relatively low >>> > throughput would want to protect their communication via SSL. >>> > >>> > The ways I have seen the community deal with this are mainly: >>> > >>> > 1. Go through the pain of learning SSLEngine (and hope to get it right) >>> > 2. Build their services around tested libraries (like Jetty, which handle >>> > the SSL offload but don't resurface it in SocketChannel/Selector paradigm, >>> > that also come with their huge set of dependencies, bringing in >>> > unavoidable >>> > version collisions) >>> > 3. Use proxies (nginx, ha) to deal with the high number of SSL connections >>> > and divide the load by scaling horizontally in the back end (making for a >>> > harder deployment model) >>> > >>> > We can make this a lot easier! >>> > >>> > Any feedback is greatly appreciated, >>> > Best, >>> > >>> > Andi Mullaraj >>> > -- - DML
