[
https://issues.apache.org/jira/browse/DIRMINA-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18100937#comment-18100937
]
Emmanuel Lécharny commented on DIRMINA-1200:
--------------------------------------------
Here is a schema of what is happening when receiving big chunk of encoded data:
{code:java}
input mDecodedBuffer
+----+ +----+
|1024| -> |1024|
+----+ +----+
+--------+ +----+--------+
| 2048 | -> |1024| 2048 | 3072
+--------+ +----+--------+
+------------+ +----+--------+------------+
| 4096 | -> |1024| 2048 | 4096 | 7168
+------------+ +----+--------+------------+
+----------------+ +----+--------+------------+----------------+
| 8192 | -> |1024| 2048 | 4096 | 8192 | 15360
+----------------+ +----+--------+------------+----------------+
+--------------------+
+----+--------+------------+----------------+--------------------+
| 16384 | -> |1024| 2048 | 4096 | 8192 |
16384 | 31744
+--------------------+
+----+--------+------------+----------------+--------------------+
^ ^
^
| |
|
+----- First chunk of data, 16367 bytes ------+--
some more --+
{code}
As we can see, we start small, reallocate many times two buffers, before we can
actually decode a packet of data.
> 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]
