Added close_abort() function to WiFiClient#2767
Added close_abort() function to WiFiClient#2767pfabri wants to merge 10 commits intoesp8266:masterfrom
Conversation
This branch adds a close_abort() method to the WiFiClient class.
How it works, what it does:
Calling `close_abort()` will close and abort the client connection it
is invoked on and, as a result, free its resources (i.e. memory).
**WARNING:** aborting connections without a good reason violates the
TCP protocol, because a closed connection would normally need to
spend some time in `TIME_WAIT` state before its resources are freed.
Usage example:
WiFiClient client; // set up a client
{ /* do things with your client */ }
client.stop_abort() // when you're done,abort the
// connection if you must
Why it's useful:
1. Give programmers a way to shut down connections immediately if
need be. The underlying `tcp.c` file has an abort function, but
this has not been directly accessible via the `WiFiClient`
class until now.
2. There are a number of reported issues for the repository
addressing the heap corruption that can result from trying to
retain too many connections in `TIME_WAIT` state (most notably:
esp8266#230, esp8266#1070, esp8266#1923). Although the warning above holds, there may be
circumstances where this isn't very important. For example an ESP8266
running in AP mode hosting a page, which requests a new
connection every second via an AJAX script to monitor
a sensor/button/etc. continusously.
Currently existing alternative approach:
When building a project, defining the
`-D MEMP_NUM_TCP_PCB_TIME_WAIT=5`compiler directive will limit the
maximum number of clients allowed to stay in TIME_WAIT state. `5` is
the default, lower it as necessary. See reference
[here](https://github.com/esp8266/Arduino/blob/master/tools/sdk/lwip/include/lwipopts.h#L263)
Thanks:
Thank you to @me-no-dev, @everslick and @Palatis for bringing the `
MEMP_NUM_TCP_PCB_TIME_WAIT` option to my attention.
Current coverage is 27.80% (diff: 100%)@@ master #2767 diff @@
==========================================
Files 20 20
Lines 3625 3625
Methods 335 335
Messages 0 0
Branches 656 656
==========================================
Hits 1008 1008
Misses 2441 2441
Partials 176 176
|
|
We at the ESPEasy project need this as well: Sometimes we need to make a lot of new connections in a short time, causing memory problems. Cant seem to find a workaround that does not involve patching Wificlient itself. |
|
Thanks a lot! This solved my issue after hours of searching for the memory leak in my server application.. lost 1.6kB of heap within 10 messages with different clients. @shimizutko if you are still interested in it: I just added the changes to those files regardless of any other differences. This worked perfectly. And I'm calling stop_abort instead of stop of course. |
|
a cleaner workaround that doesnt require changes to core libraries: #1923 (comment) |
|
Thanks for your answer! Funny thing is, I also found that, but it does not make any difference at all. I put this code before any includes except Arduino.h as I get an error if I put it before Arduino.h or use my code without Arduino.h. |
|
Did you also call tcpCleanup() in loop() ?
…On Jul 14, 2017 09:21, "Kevin Köck" ***@***.***> wrote:
Thanks for your answer! Funny thing is, I also found that, but it does not
make any difference at all. I put this code before any includes except
Arduino.h as I get an error if I put it before Arduino.h or use my code
without Arduino.h.
It just does not make any difference for me. If it did, it would be the
better workaround of course.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2767 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AB0jL7VAFM7An0mgVjUSauj_Ned59b1rks5sNxb7gaJpZM4LOmpj>
.
|
|
Thanks a lot! This does work quite well! Forgive me, I somehow forgot to call that function.. |
|
yeah you have to call it at a point you think there is some cleaning up to do. or just in loop(). no harm in calling it too often i think. |
|
@d-a-v, I think this is no longer needed with your TIME_WAIT fixes. If so, can you please close? |
|
Thanks for your PR, but the core and libraries have changed enough that this PR now has a merge conflict. Could you merge it manually with the latest core, so we can consider it for future releases? |
|
This has a conflict, pushing back. |
The primary goal of this PR has indeed been fixed by @me-no-dev's patch that is ported to lwip2. |
|
Without feedback and due to old age, also with another fix addressing the original issue that is already in the core, this PR should be closed. |
This branch adds a close_abort() method to the WiFiClient class.
How it works, what it does:
Calling
close_abort()will close and abort the client connection itis invoked on and, as a result, free its resources (i.e. memory).
WARNING: aborting connections without a good reason violates the
TCP protocol, because a closed connection would normally need to
spend some time in
TIME_WAITstate before its resources are freed.Usage example:
Why it's useful:
Give programmers a way to shut down connections immediately if
need be. The underlying
tcp.cfile has an abort function, butthis has not been directly accessible via the
WiFiClientclass until now.
There are a number of reported issues for the repository
addressing the heap corruption that can result from trying to
retain too many connections in
TIME_WAITstate (most notably:Memory leak ESP8266WebServer #230, memory leak by using WiFiClient (40 Byte per usage) #1070, memory leak 184 bytes at a time #1923). Although the warning above holds, there may be
circumstances where this isn't very important. For example an ESP8266
running in AP mode hosting a page, which requests a new
connection every second via an AJAX script to monitor
a sensor/button/etc. continusously.
Currently existing alternative approach:
When building a project, defining the
-D MEMP_NUM_TCP_PCB_TIME_WAIT=5compiler directive will limit themaximum number of clients allowed to stay in TIME_WAIT state.
5isthe default, lower it as necessary. See reference
here
Thanks:
Thank you to @me-no-dev, @everslick and @Palatis for bringing the
MEMP_NUM_TCP_PCB_TIME_WAIToption to my attention.