On Fri, May 3, 2013 at 3:47 PM, Emmanuel Lécharny <elecha...@gmail.com>wrote:
> Le 5/3/13 3:40 PM, Jeff MAURY a écrit : > > +1 > > > > I think we shall rewrite the code and let be driven by the underlying > > SSLengine status. > Absolutely. I have created a branch to play a bit with SSL. > > Now, if after processing there are still remaining data in the input > > buffer, we must keep it until the next buffer is received. > Thus the compact(). > > The pb is for the normal calls (ie, not SSL- as the buffer can be > propagated up to the user. In this case, if we compact the buffer, we > may get some weaird side effect if the user has done some weird things > wih the buffer. > Why do we need to take care of non SSL configuration in this SSL discussion ? > > 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 ? > That's an option. > > However, internally, the SslEngine does copy the ByteBuffer if it's not > a Direct buffer. So I'm not sure we can spare any CPU time by > concatenating the received ByteBuffer into a composite structure. > I think so as I suspect the SSLEngine to be message oriented so when an input buffer is given, then the SLL engine will read the first bytes to decode the length and if not enough data is present, it will throw a BufferUnderflow so only the first bytes of the input buffer will be read and taht's why we need to concatenate. > > I mean, if we pass a DirectBuffer to the SslEngine, it will be faster. > If this DirectBuffer does not contain enough data to produce an > unwrapped buffer, the we will have to pass a new DirectBuffer containing > the previous data (copied from the previous DirectBuffer) plus the newly > read data. In any case, we have some copy... > I don't think so. Jeff > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > > -- 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
