On extending java.nio.ByteBuffer : it's not doable because the constructor is private :(
On Fri, May 3, 2013 at 3:40 PM, Jeff MAURY <[email protected]> wrote: > +1 > > I think we shall rewrite the code and let be driven by the underlying > SSLengine status. > Now, if after processing there are still remaining data in the input > buffer, we must keep it until the next buffer is received. > In order to preserve performances, as we need to assemble the input buffer > with the rest of the previous input buffer, I had the idea of having a > CompositeReadOnlyByteBuffer that extends ByteBuffer and that will be > composed of the two buffers. This will prevent to perform costly copies > while allowing the SSLEngine to see the whole data. > Any thoughts ? > > Jeff > > > On Fri, May 3, 2013 at 3:19 PM, Emmanuel Lécharny <[email protected] > >wrote: > > > Hi guys, > > > > the way we handle incomming SSL data on the server will not work if the > > data are fragmented. > > > > Let's say we are receiving some Handshake data. This is typically a few > > hundreds of bytes, that usually comes in one block. In this case, we are > > all good. But if those data aren't read in one block, then we are dead. > > > > I have simulated such a fragmentation by sending a ClientHello block of > > data in three parts : as soon as the SslEngine if given the second block > > of data, it throws an exception : > > 2013-05-03 15:07:15,546 ERROR [SelectorWorker Server-I/O-1] > > tcp.NioTcpSession (NioTcpSession.java:330) - Exception while reading : > > javax.net.ssl.SSLException: Unsupported record version Unknown-0.0 > > at > > > > > sun.security.ssl.EngineInputRecord.bytesInCompletePacket(EngineInputRecord.java:116) > > at > sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:845) > > at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:758) > > at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) > > at org.apache.mina.session.SslHelper.unwrap(SslHelper.java:190) > > > > > > This is plain normal : when we read the first block of data, we unwrap > > it, and the SslEngine resturn with a BUFFER_UNDERFLOW status (expected). > > Now, we return back to the main loop, and we *clear* the reaBuffer. We > > then lose the first bytes we have read, parts that the SslEngine is > > expecting to have the next time we call it. > > > > There is one way to avoid such a problem : we just have to compact the > > buffer instead of clearing it. > > > > Now, regarding the SSL code, it's really messy atm. The fact that we > > separate the handshake from the normal processing of data is wrong. When > > we do an unwrap, it will initiate a handshake if needed. The fact is we > > have to review the full code and rewrite it... > > > > I'm currently doing some experiments here, but I would be please to > > share ideas, suggestion, proposals from any of you... > > > > > > -- > Jeff MAURY > > > "Legacy code" often differs from its suggested alternative by actually > working and scaling. > - Bjarne Stroustrup > > http://www.jeffmaury.com > http://riadiscuss.jeffmaury.com > http://www.twitter.com/jeffmaury >
