Re: [lwip-users] altcp_tls_mbedtls

[Giuseppe Modugno]

Il 25/02/2019 20:19, address@hidden 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.