|
From: | Joel Cunningham |
Subject: | Re: [lwip-users] TCP keep-alive not working on half-closed connections |
Date: | Wed, 06 Jun 2018 14:58:48 -0500 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 |
On 06/06/2018 02:13 PM, address@hidden wrote:
https://stackoverflow.com/questions/18110239/does-tcp-endpoint-that-has-sent-a-fin-still-send-keepalive https://social.msdn.microsoft.com/Forums/en-US/d20e5e67-d23c-42a5-95c5-ba80f4263546/keepalive-packets-continue-being-sent-after-client-closes-server-socket-is-closewait-client Here's some findings on a FIN_WAIT_2 timeout: https://serverfault.com/questions/738300/why-are-connections-in-fin-wait2-state-not-closed-by-the-linux-kernel https://www.akronohio.gov/manual/misc/fin_wait_2.html I don't believe a FIN_WAIT_2 timeout is implemented in LwIP.No, we don't have that. We always said it's OK for a connection to stay in FIN_WAIT_2. However, it seems we must handle this differently depending on wether the user has called "shutdown" or "close". Then we can implement a timeout.
Agreed, if the application used shutdown() on only the TX pathway, we would not want to start a timeout until the RX pathway is also shutdown. Maybe even further delay the timeout until the app is done with the socket as indicated by close().
You're right, I forgot the behavior was changed somewhat recently to not kill same priority anymoreI'm also thinking this issue may not be that common since tcp_alloc would reap the half-open connection eventually to prevent pcb exhaustionI don't think tcp_alloc will kill pcbs in FIN_WAIT_2 unless they have a lower priority. A timeout on FIN_WAIT_2 *does* make sense!
Joel
[Prev in Thread] | Current Thread | [Next in Thread] |