|
From: | Giuseppe Modugno |
Subject: | Re: [lwip-devel] [mqtt] Disconnection caused by a keep-alive timeout |
Date: | Thu, 3 Dec 2020 11:37:33 +0100 |
User-agent: | Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 |
Il 03/12/2020 10:54, Benjamin Kalytta ha scritto:
I don't know if my problem is related since I relied on Netconn API. In that case, my embedded device was running a HTTP web server. Clients connected through Wi-FI to my device. AJAX requests were heavily used i.e. many connections opened and closed very often. As soon as the client (running on Microsoft Windows) loses the Wi-FI connection Windows automatically shuts down all active TCP/IP connections since this network interface wasn't available any more (This should not be conform to the TCP/IP specification!). However, the embedded device did not notice that the connections on the opposite side were already closed, so no pool memory were ever freed. When the Wi-FI connection reestablished, and the client tries to reconnect, no more memory was available to handle that client requests.
Yes, I think it's related. TCP/IP stack tries to close all connections in the best way it can, even if this means keeping data in memory for a very long time. During this time your system has a lower quantity of free memory to use for new connections. Because in embedded systems often we don't have big memories, this could be a critical issue.
My solution was to enable TCP/IP keep-alive per connection and setting a reasonable short timeout. Following configuration has to be set for that to work reliably: #define LWIP_NETCONN_FULLDUPLEX 1 #define LWIP_NETCONN_SEM_PER_THREAD 0
I didn't know the keep-alive feature of TCP stack. In my case I already have an application protocol (MQTT) that can be configured to use keep-alives (at application layer). If the application detects a faulty connection with the peer (no reply to the keep-alive request), it closes the TCP socket. In this situation, I think it is safe (maybe better) to use tcp_abort(), that free everything related to the connection, instead of tcp_close(), that will try to send unacked data.
[Prev in Thread] | Current Thread | [Next in Thread] |