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. > 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 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... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
