[
https://issues.apache.org/jira/browse/DIRMINA-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817977#comment-16817977
]
Emmanuel Lecharny commented on DIRMINA-1105:
--------------------------------------------
We can also improve the way we manage incoming {{TLS}} messages, by using a
thread local storage buffer.
Most of the time, when we call {{SSLEngine.unwrap()}}, the message is complete
(ie, it contains all what is needed to be unwrapped). Sometime, due to {{TCP}}
fragmentation, it's not, and we get back a {{BUFFER_UNDERFLOW}}, then we have
to wait for more bytes to be read, and recall the unwrap method once more,
until we get the full message.
I suggest to always feed the read data into the thread local storage buffer,
call {{unwrap}} with that, and if it returns {{BUFFER_UNDERFLOW}}, allocate a
temporary buffer stored in the session attributes, which will be discarded when
the unwrapping will be done (or not).
If we don't get too many fragmented buffers, this approach should be beneficial
in term of memory consumption (no need to allocate a temporary buffer), which
is a huge potential gain when we have thousands of sessions. Marginally, we may
have to allocate a buffer for fragmented data, but this cost is already present
in the current implementation (this buffer is allocated when the filter is
added into the session's chain).
> SSLHandler buffer handling
> --------------------------
>
> Key: DIRMINA-1105
> URL: https://issues.apache.org/jira/browse/DIRMINA-1105
> Project: MINA
> Issue Type: Improvement
> Affects Versions: 2.0.21, 2.1.1
> Reporter: Emmanuel Lecharny
> Priority: Major
>
> The {{SSLEngine.wrap()}} method requires the provided buffer to be 'big
> enough' to contain any kind of *SSL/TLS* message. That means 16921 bytes. The
> way it's implemented is that we allocate such a buffer every time we need to
> call the {{wrap}} method, then we copy the result into a smaller buffer that
> is injected into thee write queue.
> This is quite ineficient. It would rather be a better idea to use a Thread
> Local Storage buffer when calling the {{wrap}} method, and copy the content
> into a temporary buffer.
> Another optimization could be to concatenate the successive calls to the
> {{wrap}} method into a single buffer, that will be sent in one shot (it's
> frequent that more than one call to {{wrap}} is needed during the handshake).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
