Hi,
when we process some incoming data over a secured connection, at some
point, we must decrypt the data.
We receive an encrypted buffer, then we call the unwrap method, and we
obtain a decrypted buffer :
[$*#@X] --unwrap--> [ABCDE]
The key here is that we will have to deal with data fragmentation, and
internal buffer will be needed to accumulate the incoming bytes, plus
the outgoing bytes.
That raises a question : what is the best size for those buffers ? We
can't simply increase the buffer size until we get an OOME, nor we can
limit statically the buffer size to an hard coded size.
SSL RFC's define a default maximum buffer size, 16K, except that some
faulty implementations will send 32K SSL messages. Also the resulting
decrypted message may be bigger than the incoming bytes, as it's compressed.
So we have to define 2 buffers :
- one to accumulate the incoming data if the message is split,
- one to store the decrypted message, which may need to be expanded if
we can't put everything in it.
I would suggest we do something like :
- use the default buffer (64kb) and try to unwrap it into an application
buffer (128k). If the incoming buffer contains a complete message, and
if the application buffer is big enough, we are done.
- if we have to use a bigger application message, then we will allocate
a new one, and pass it to the application. It will be associated with
the session, and must be released at the end
- if the incoming message is not containing everything needed, then it's
copied into a session buffer (32kb), and aggregated with the existing
data, until we can unwrap it.
If everything works fine, we should not be forced to use any session
dedicated buffers, limiting the number of buffers to 2 : one for the
incoming data, one for the application data, for each selector.
Otherwise, we may have to allocate some buffers associated with each
session (and we should take care of the memory allocation).
wdyt ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
