Jan Menzel wrote:
At the end, the buffer size required for encrypting/decrypting
transmitted/received data is something, that depends on your setup and
on configuration options commonly available. So, if you carefully
control and debug your setup you probably can run with less memory.
Jan, could you explain this a bit more detailed? How I see it, my memory
problems was the per-connection allocation and there, the biggest chunks
were the frame buffer for RX & TX (mbedTLS: *MBEDTLS_SSL_MAX_CONTENT_LEN
*define). Now if you know the pages served (or at least the algorithm
calling write), you know the required buffer for TX, but at least when
providing file upload via HTTPS (e.g. firmware update), I'm not sure how
the RX buffer could be reduced.
Unfortunately, the buffer size negotiation is not mandatory for web
browsers.
Simon
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
