mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DIRMINA-1105) SSLHandler buffer handling
Date Mon, 15 Apr 2019 13:44:00 GMT

    [ 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

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

View raw message