[
https://issues.apache.org/jira/browse/DIRMINA-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18100941#comment-18100941
]
Emmanuel Lécharny commented on DIRMINA-1200:
--------------------------------------------
One more note: if we decide to check the TLS application data size (byte 4 and
5), we absolutely need to take care f the case where we have not received those
2 bytes: we may have received the 3 starting TLS packet bytes, but not those 2
bytes (actually, we even may have received only one byte...
> 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]
