[
https://issues.apache.org/jira/browse/DIRMINA-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18100938#comment-18100938
]
Emmanuel Lécharny commented on DIRMINA-1200:
--------------------------------------------
It would make sense to allocate a 16Kb input buffer 'just in case' when in
secured mode, and only allocate the mDecodedBuffer when we know we have
received enough data to hold a whole application data block, then and only then
we can call the `SslEngine.unwrap` method.
> Avoid creating useless reception buffers when using TLS
> -------------------------------------------------------
>
> Key: DIRMINA-1200
> URL: https://issues.apache.org/jira/browse/DIRMINA-1200
> Project: MINA
> Issue Type: Improvement
> Affects Versions: 2.2.9
> Reporter: Emmanuel Lécharny
> Priority: Major
>
> When receiving big messages (like 64Kb) on a TLS session, we start by reading
> a 1Kb buffer, which is obviously too small, then we increase the buffer size
> (2Kb, then 4Kb, etc up to 32Kb) until we have process the incoming message
> fully.
> Each of those buffers get ditched after having been copied into the newly
> allocated buffer.
> So if we transmit a 64Kb message, which will be hold in 5 TLS ApplicationData
> TLS messages, we allocate 7 buffers, for a total of 64Kb, for each TLS
> packet, when it would have been enough to allocate a 16Kb message, enough to
> hold a full TLS packet.
> Actually, we would still need to process the first 1Kb message as it contains
> the TLS frame with the data size (bytes 4 and 5 in the TLS header), enough
> information for the proper buffer allocation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
