Resolved issue #3359 (#6969)

* Resolved issue #3359

Made severing connections optional as per the patch
in the issue.
Also fixed a minor spacing issue.

* Renamed sever to close and added information to readme

Also my editor automatically removed some odd whitespace at the
end of a few lines.

Author: timstableford

doc/ota_updates/readme.rst

@@ -61,7 +61,7 @@ As shown below, the signed hash is appended to the unsigned binary, followed by
 
 .. code:: bash
 
-    NORMAL-BINARY <SIGNED HASH> <uint32 LENGTH-OF-SIGNING-DATA-INCLUDING-THIS-32-BITS> 
+    NORMAL-BINARY <SIGNED HASH> <uint32 LENGTH-OF-SIGNING-DATA-INCLUDING-THIS-32-BITS>
 
 Signed Binary Prerequisites
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -200,11 +200,11 @@ The following chapters provide more details and specific methods for OTA updates
 Arduino IDE
 -----------
 
-Uploading modules wirelessly from Arduino IDE is intended for the following typical scenarios: 
+Uploading modules wirelessly from Arduino IDE is intended for the following typical scenarios:
 
--  during firmware development as a quicker alternative to loading over a serial port, 
+-  during firmware development as a quicker alternative to loading over a serial port,
 
--  for updating a small number of modules, 
+-  for updating a small number of modules,
 
 -  only if modules are accessible on the same network as the computer with the Arduino IDE.
 
@@ -510,6 +510,11 @@ HTTP Server
 
 ``ESPhttpUpdate`` class can check for updates and download a binary file from HTTP web server. It is possible to download updates from every IP or domain address on the network or Internet.
 
+Note that by default this class closes all other connections except the one used by the update, this is because the update method blocks. This means that if there's another application receiving data then TCP packets will build up in the buffer leading to out of memory errors causing the OTA update to fail. There's also a limited number of receive buffers available and all may be used up by other applications.
+
+There are some cases where you know that you won't be receiving any data but would still like to send progress updates.
+It's possible to disable the default behaviour (and keep connections open) by calling closeConnectionsOnUpdate(false).
+
 Requirements
 ~~~~~~~~~~~~
 

libraries/ESP8266httpUpdate/src/ESP8266httpUpdate.cpp

@@ -345,8 +345,10 @@ HTTPUpdateResult ESP8266HTTPUpdate::handleUpdate(HTTPClient& http, const String&
 
                 WiFiClient * tcp = http.getStreamPtr();
 
-                WiFiUDP::stopAll();
-                WiFiClient::stopAllExcept(tcp);
+                if (_closeConnectionsOnUpdate) {
+                    WiFiUDP::stopAll();
+                    WiFiClient::stopAllExcept(tcp);
+                }
 
                 delay(100);
 

libraries/ESP8266httpUpdate/src/ESP8266httpUpdate.h

@@ -87,6 +87,11 @@ class ESP8266HTTPUpdate
         _followRedirects = follow;
     }
 
+    void closeConnectionsOnUpdate(bool sever)
+    {
+        _closeConnectionsOnUpdate = sever;
+    }
+
     void setLedPin(int ledPin = -1, uint8_t ledOn = HIGH)
     {
         _ledPin = ledPin;
@@ -146,12 +151,13 @@ class ESP8266HTTPUpdate
     // Set the error and potentially use a CB to notify the application
     void _setLastError(int err) {
         _lastError = err;
-	if (_cbError) {
+        if (_cbError) {
             _cbError(err);
         }
     }
     int _lastError;
     bool _rebootOnUpdate = true;
+    bool _closeConnectionsOnUpdate = true;
 private:
     int _httpClientTimeout;
     bool _followRedirects;