- Only allow one TCP segment in flight. Each segment is 1.5K and it
adds up. This may increase latency, but memory is precious on ESP.
At teh same time, optimize use of tcp_output: do not send a new segment
on every write, only call tcp_output at the end of connection
processing during poll.
- Build LWIP with DNS disabled. We have our won resolver, and LWIP's
allocates large static buffers (1K).
- mbedTLS: Deallocate peer's certificate at the end of SSL handshake,
reduces idle SSL connection footprint by ~1.5K.
Some tweaks to the heap log viewer (which made all the above possible).
PUBLISHED_FROM=6e84bba64eacb2d737561e09313918104921ea80
Also performs trnasparent SPIFFS -> SLFS cert copy.
If the file's extension is .pem, convert it to DER format and put on SLFS.
PUBLISHED_FROM=364caab21969ca28a05802c4dde93a11d1e0feda
Also fixed a memory leak on reconnect: previously, each reconnect was
creating a `struct mg_connection` which was never reclaimed
PUBLISHED_FROM=eefdcf557e032ac81d5ed3aba55ac912e400148e
The only client of `mg_http_common_url_parse` (namely,
`mg_connect_http_base`) expects `port_i` to be the index in the address
string at which the port was added.
PUBLISHED_FROM=b095926b5485e4674e3c59ff8481171831fb61ae
If the path starts with /, do not drop it.
There are no directories on SLFS, but use of /pretend/paths/to/files.txt
is common. What we do drop is the ./ prefix (added by mongoose when document_root=.)
PUBLISHED_FROM=5108bc078dfaf8f8afa4db554b4769d9d7b8a103
It wasn't checked for `NULL`, and on CC3200 NULL dereferencing addresses
doesn't cause a crash, so it worked by pure luck: ctx->ssl_key was 0.
After `mg_` to `miot_` refactoring it's not the case anymore (presumably
because linker arranged objects in a different order), so this bug shown
up.
PUBLISHED_FROM=0f1cc73a078c18432c68ae0f9b14dd06b3bb4279
in light of the root cause discovered by rojer
and addressed in cesanta/dev#5882 for the http connection code path.
PUBLISHED_FROM=aea563150a0411cbe3fdc6f7911529f3136cc76f
Long-lived UDP "connections" i.e. interactions that involve more
than one request and response are rare, most are transactional:
response is sent and the "connection" is closed. Or - should be.
But users (including ourselves) tend to forget about that part,
because UDP is connectionless and one does not think about
processing a UDP request as handling a connection that needs to be
closed. Thus, we begin with SEND_AND_CLOSE flag set, which should
be a reasonable default for most use cases, but it is possible to
turn it off the connection should be kept alive after processing.
PUBLISHED_FROM=1677d8024aa9afa7e18d8a04d829b699f7f2f103
Deomid Ryabkov