Il 25/02/2019 20:19, goldsi...@gmx.de ha scritto:
Am 22.02.2019 um 10:24 schrieb Giuseppe Modugno:
Il 22/02/2019 09:43, Simon Goldschmidt ha scritto:
[snip]
Is this warning correct? I think TCP_WND should be compared with
MBEDTLS_SSL_IN_CONTENT_LEN or MBEDTLS_SSL_OUT_CONTENT_LEN or the
maximum
of them (of course, I hope to compare it with OUT buffer only, because
it is smaller).
I think you're right: this should compare to the IN buffer. No that it
would help you here... :-)
I'm not an expert here, so my question could be very stupid. TCP_WND is
the TCP window that is used to avoid continuous ack for small data. The
transmitter sends data filling the window and then waits for the ack.
TCP_WND is what we announce to the remote host to be able to buffer
for RX.
For TX, what we buffer is the minimum of what the remote host tells us
to be able to buffer and the memory we have/allow (both available heap
memory and the limitation defines SND_BUF and SND_QUEUE_LEN).
Ok, but I couldn't understand the relation between lwip receiving window
and TLS incoming buffer. If MBEDTLS_SSL_IN_CONTENT_LEN is 16kB, should I
need a TCP_WND at least 16kB, for a total of 32kB of memory only to
handle incoming TLS traffic?
Suppose I have a TCP_WND of only 2kB and incoming TLS buffer of 16kB.
The TLS transmitter could send maximum 2kB of data that are buffered in
the lwip receiving window. lwip calls altcp_recv(), so
altcp_mbedtls_lower_recv() with received data (2kB maybe segmented in
small pbufs and pbuf chains).
I can't follow the code, but I expect those data are immediately passed
to mbedTLS library that should copy those data to its 16kB incoming
buffer, freeing receiving window. I think the lwip TCP receiving window
could be smaller than mbedTLS incoming data buffer.
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users