Added close_abort() function to WiFiClient

[pfabri]

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:
   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 the
maximum number of clients allowed to stay in TIME_WAIT state. 5 is
the 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_WAIT option to my attention.

[codecov-io]

Current coverage is 27.80% (diff: 100%)

Merging #2767 into master will not change coverage

@@             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          

Powered by Codecov. Last update 7b32e6a...9fac290

[psy0rz]

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.

[kevinkk525]

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.
Why is this commit still not merged into the main branch?
I somehow doubt that this problem is so minor that it can be ignored. or is my server software doing something wrong by not closing the connection or similar?

@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.

[psy0rz]

a cleaner workaround that doesnt require changes to core libraries: #1923 (comment)

[kevinkk525]

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.

[everslick]

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> .

[kevinkk525]

Thanks a lot! This does work quite well! Forgive me, I somehow forgot to call that function..
Thank you for all the help!

[psy0rz]

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.

[earlephilhower]

@d-a-v, I think this is no longer needed with your TIME_WAIT fixes. If so, can you please close?

[earlephilhower]

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?

[devyte]

This has a conflict, pushing back.

[d-a-v]

I think this is no longer needed with your TIME_WAIT fixes. If so, can you please close?

The primary goal of this PR has indeed been fixed by @me-no-dev's patch that is ported to lwip2.
If such an API is not needed for other purpose we can close this PR.

[d-a-v]

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.
It can be reopened after discussion, if any.