W5500 - ACK's Keep Alive when KPALVTR is 0

Question

Hi - I am using the W5500 as a Web Server and noticed that Chrome doesn’t always reply with FIN, ACK when the Web Server sends a “disconnect”. Instead, Chrome sends Keep Alive requests until Chrome is closed. Meanwhile, the W5500 sends an ACK for the Keep Alive packets even though the Sn_KPALVTR is set to 0. According to the data sheet, the automatic Keep Alive process should be disabled. I’m wondering if anyone has found a way to force the W5500 from ACKing Keep Alive packets? EDIT: Never mind, my bad - I see the KPALVTR is for sending a Keep Alive packet, not responding to KA packets.

Eugeny · Answer

Wizboy: Instead, Chrome sends Keep Alive requests until Chrome is closed. There’s a known bug, or feature (up to you how you see it). Chrome opens several concurrent TCP connections to the web server, and reuses them when it needs. It does not close these connections when finished transferring data, keeping W5500 sockets allocated and not available for further connections. Solution to this issue is changing browser you use - to Firefox. It has special setting (which Chrome was missing at the time of my investigation) network.http.max-persistent-connections-per-server. Setting it to (for example) 2 will cause Firefox opening only 2 TCP persistent connections to W5500, and you will be guaranteed having 6 remaining sockets free for other connections.

Eugeny · Answer

That seem to be a workaround, but I think closing socket without notifying (through disconnect) may confuse browser and you may have some documents reported as failed to load (e.g. “X” instead of pictures on the web page). However if you do immediate disconnect, there’s a risk that Chrome will be trying to reopen the connection. Check if newer versions of Chrome are having such option as FF now.

Wizboy · Answer

Your suggestion to use disconnect instead of close work better - thanks. I see now the issue is if I disconnect if no data, sometimes Chrome displays: ERR_EMPTY_RESPONSE. What is happening is that sometimes the data (GET request) doesn’t arrive at the time the W5500 has switched to ESTABLISHED. So what I need to do is as soon as ESTABLISHED, I should wait for a period of time “just in case” Chrome wants to send some data for that socket. Have you run into something like this and if so how did you resolve it? (i.e., if you put in a wait loop, how long before the wait loop should stop waiting and then disconnect)? Thanks!

Eugeny · Answer

Wizboy: Have you run into something like this Yes, and that’s why I know about this issue. I also experienced this “ERR_EMPTY_RESPONSE” issues and empty pictures on the web page, stuck sockets for a while (Chrome can keep sockets connected for minutes without activity). Wizboy: how did you resolve it I did not find satisfactory workaround for Chrome, and decided to use Firefox as people in Chrome support confirmed that Chrome does not have an option to limit number of concurrent connections. It may be that waiting for 5 seconds would be enough, but who knows how Chrome operates and that you do not get ERR_EMPTY_RESPONSE in most interesting moment.

Wizboy · Answer

After some searching in the Chrome bug logs, I did find a work around for this “feature” for Chrome users who need it. Turn off the “Use a prediction service to load pages more quickly” option in Advanced Settings. Chrome calls this feature “preconnect”. My earlier discovery of a different behavior in Incognito mode is due to a bug in Chrome. So…hard to tell now which one is the bug and which one is the feature!! EDIT: Eugeny is correct in that there isn’t a way (as of version 61) to disable preconnect from the server. This has to be switched off in the individual browser settings.