I forgot about and forgot to mention there is a special backpressure in the webpieces implementation.
Say A connects through socket to B and B has this webpieces channelmanager. Let's say C is the client code of B. If C does not consume the data fast enough from A, channelmanager deregisters the socket to A to PAUSE reading from A until C catches up. Once C catches up, it re-registers the socket un-pausing. This yields a graceful performance degredation AND it turns out an increase in performance due to less 'jittering' ...a term from the audio world. It's a very complex topic and hard to explain the reasons behind it. Anyways, it was quite an interesting experience. On Wed, Feb 13, 2019 at 9:21 AM Dean Hiller <[email protected]> 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 <[email protected]> > 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 >> > >> >
