I'm using a Wiznet W5300 as a TCP server that waits for a client connection and then pushes data without receiving any data. It will run for many hours and then a socket will stop. The W5300 never sets the "SENDOK" flag which is an internal flag that indicates the previous send was accepted (may or may not have gone out physically) and I can send more data. I'm not sure if there's a bug in that chip, but I'd like to understand on the network level what if anything could possibly cause a TCP connection to stall.
The W5300 reports the TCP connection as still established, and the client reports the connection as good, but doesn't receive any data anymore. The data is moving at maximum throughput, so I would expect buffers to fill up on a regular basis.
If I understand, when someone sends an ACK, it includes a window size of how much more data it can receive. Is it possible that the client buffer fills up, it sends an ACK with 0 window size, and then it reads some data and sends an ACK with a non-zero window size, but that second ACK gets lost? If that happened, what would ever cause a recovery? Might a keepalive (which is an option in the W5300) force an updated ACK with a current window size?
Are there any other reasons a TCP connection might get held up? The W5300 seems to have a strange status in a reserved byte, and I'm inquiring with them if it might have some meaning I can use, but other than that, it seems like it just gets held up waiting for the previous send to go through.
I've played a little with Wireshark but I'm thinking it's not a great method to debug this since it happens seemingly randomly after many hours, and the amount of data collected would be many Gigabytes.
Thanks for any ideas.
The W5300 reports the TCP connection as still established, and the client reports the connection as good, but doesn't receive any data anymore. The data is moving at maximum throughput, so I would expect buffers to fill up on a regular basis.
If I understand, when someone sends an ACK, it includes a window size of how much more data it can receive. Is it possible that the client buffer fills up, it sends an ACK with 0 window size, and then it reads some data and sends an ACK with a non-zero window size, but that second ACK gets lost? If that happened, what would ever cause a recovery? Might a keepalive (which is an option in the W5300) force an updated ACK with a current window size?
Are there any other reasons a TCP connection might get held up? The W5300 seems to have a strange status in a reserved byte, and I'm inquiring with them if it might have some meaning I can use, but other than that, it seems like it just gets held up waiting for the previous send to go through.
I've played a little with Wireshark but I'm thinking it's not a great method to debug this since it happens seemingly randomly after many hours, and the amount of data collected would be many Gigabytes.
Thanks for any ideas.
Last edited: