mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: [MINA 3] SSL and fragmentation
Date Fri, 03 May 2013 13:47:14 GMT
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...

Emmanuel Lécharny

View raw message