[
https://issues.apache.org/jira/browse/DIRMINA-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18100344#comment-18100344
]
Emmanuel Lécharny edited comment on DIRMINA-1200 at 8/1/26 6:08 AM:
--------------------------------------------------------------------
Also note that each one of those intermediary buffers get parsed by the
SslEngine before being discarded. Add to that we also allocate the resulting
buffer that also get ditched. All in all, we allocate 2 buffers many times for
nothing...
There is some room for improvement...
was (Author: elecharny):
Also note that each one of those intermediary buffers get decoded fully before
being discarded. Add to that we also allocate the resulting buffer that also
get ditched. All in all, we allocate 2 buffers many times for nothing...
There is some room for improvement...
> 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]
