3 ms·
"It's possible for one system to think it has a working, established TCP connection to a remote system, while the remote system knows nothing about that connect
by testemailfordg2 3y ago
"It's possible for one system to think it has a working, established TCP connection to a remote system, while the remote system knows nothing about that connection."
I have this problem right now, between applications in on-premise DC and public cloud, talking over a VPN.
If there is a blip on the network, or a firewall failover happens, the other side continues to think its connected. So, to ensure my application side is resilient, we configure the listeners to go back to listening mode, if nothing received for 5 minutes. This ensures we don't have to manually intervene and the connection comes back up on its own.
- taneq 3y agoYeah, I've seen a lot of code doing "the right thing" and trusting TCP to monitor connections. I trust none of it. My application layer always pings some status back and forth at regular intervals and both ends will disconnect after an explicitly set timeout. I'm sure there are situations (probably most static web server stuff) where this is a terrible idea but for realtime(ish) remote control it's the only way to go.
- red_admiral 3y agoWe wouldn't have had heartbleed if the SSL/TLS designers hadn't thought it necessary to include a heartbeat protocol - precisely because they couldn't trust TCP on its own to do this. (Why one would ever want to send a 4KB heartbeat packed beats me though.)