On Tue, 2007-01-16 at 10:26 +0530, Asankha C. Perera wrote: > Hi Oleg > > > We are currently working on improving the blocking version of HTTP > > connection management components in HttpConn module of HttpClient, but > > certain adjustments in priorities in order to tackle HTTPCORE-25 first > > is an option. Would you be interested in giving us a helping hand > > developing / testing a non-blocking HTTP connection manager? > > > Let me take a look at this and see if I can handle it, as its of high > importance to us. If I am successful, I will share any code back with you. >
Hi Asankha, Feel free to take the lead in this work and will happily support you in any way I can. At the very least I can promise to do code reviews, give you some feedback and suggestions, and commit the code once we are all more or less happy with the result. > > HttpCore NIO has been designed to work with any arbitrary SocketChannel, > > so adding SSL layer security should not be difficult. All it takes is > > making sure the I/O reactor instantiates the appropriate channel when > > connecting to a remote host or listening for incoming connections. The > > best approach to achieve this would be to use the good ol' factory > > pattern > > > I think there is more to do when using SSL with NIO. Check this -> > http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#SSLENG > They state why a SSLSocketChannel class is not available with the JDK. > My understanding is that we need to tackle this with the > NHttpServiceHandler and NHttpClientHandler and use the SSLEngine class > provided by the JDK to decode the byte buffers read from the NW into the > application. Yes, you are right. I messed up. I assumed SSLEngine could be used to decorate any socket channel interface but my assumption proved wrong. My bad. I appears the non-blocking SSL support will require quite a bit of work. Essentially is takes an additional filter between the I/O reactor and the protocol handler. I'll start looking into that on the weekend. Cheers, Oleg > > Please go ahead and open a feature request in JIRA. Alternatively you > > may just want to subclass the default I/O reactor impls and to override > > #connect() and #listen() methods. > > > I will wait for you reply to see how we should raise the JIRA > > thanks > asankha > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
