[jira] [Commented] (DIRMINA-1105) SSLHandler buffer handling

["Emmanuel Lecharny (JIRA)" <ji...@apache.org>]

    [ 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)