Using freertos-tcp to establish the server, when the client sends a “close” command, freertos-tcp does not close. The above is the captured packet in Wireshark.
Did you get a chance to take a look at this sample TCP echo server implementation using FreeRTOS+TCP: FreeRTOS/FreeRTOS-Plus/Demo/FreeRTOS_Plus_TCP_Minimal_Windows_Simulator/DemoTasks/SimpleTCPEchoServer.c at main · FreeRTOS/FreeRTOS · GitHub
How is the client implemented? If you wish, please share your server code.
I have closed TCP_WIN.
my code is very similar to the TCP server sample, so i don’t think my code has problem;
you may want to study rfc733 in depth and compare the behavior against tcp implementations on other platforms. Closing connections is a rather intricate process. TCP defines a grace period which needs to expire before a server closes its side of a connection; I believe that is a mechanism to allow a client to reconnect after closing. This is all documented in the connection state machine in rfc733. The infamous FIN_WAIT states you see listed when running tcpstat are testimony to this.
In short, this may be expected and specified behavior.
After the server receives the FIN packet, shouldn’t it not respond immediately with a FIN packet? The sending condition of Freertos_send is that the TCP state is not in the closed state or the half-closed state or the state waiting for closure. So when the client sends the FIN packet, Freertos_send will not send data. But now the situation is that after the client sends the FIN packet, the server is still sending data and there is no corresponding FIN packet response.
no, half closed connections are very common, sometimes deliberate, sometimes not. You may want to capture HTTP traffic on any computer on wireshark and study how both sides of a connection send their termination sequences.
I am not saying that FreeRTOS+TCP is error free, but the behavior you see very likely is TCP compliant (I would be surprised if such an elementary component of the protocl should have a so far undetected error, given how well tested that is).
After the client sends the FIN packet, the server is still sending it and there are even multiple false retransmissions. What could be the cause of this phenomenon?
Why did you choose to disable ipconfigUSE_TCP_WIN? Do you see the same behavior with TCP window enabled?
The reasons why I disabled TCP_WIN are as follows: (1) I suspect that it might be because the server sends data frequently and the client cannot respond in time, resulting in a large number of false retransmissions; (2) Without using TCP_WIN, the server’s data packets will only be sent after the client’s ACK arrives, and the prerequisite for false retransmissions does not exist; even with TCP_WIN enabled, such situations may still occur.
You appear to have a misunderstanding here. Low level ACP packets are sent by the client TCP stack regardless of how fast or the slow a client app processes the data. Retransmissions are a result of the client TCP stack failing to send the low level acknowledgements.
If the client app fails to read the data from the socket timely, this results in a shrinking window advertisement in the ACK packets (this is also visible in your traces).
Retransmissions indicate either a problem in the peer’s TCP implementation or network issues such as packets lost either in the network path (which your case does not apply) or on the receive side of your unit. Do you have a broadcast storm affecting your dut?
Can you share the PCAP capture in file format with TCP_WIN enabled?