This thread[
^] is pretty valuable as it verifies, that you are not the only one having problems with this feature. Allow me to quote one of the main points as I believe it is relevant to the problem you are experiencing on your local network:
Quote:
The mechanisms are almost exactly the same as sending your own message, only difference is the packets contains minimum of data - return contains only header, so it might be chopped away (not routed) by some routers/firewalls. In most projects I tend to end up writing a ping mechanism of my own because the other ends need to know a network fault at the same time (ping message not received within a given interval means down). Writing a mechanism of your own can also give you a quicker ways of detecting it or you have to change send timeouts etc to match your specs.
The link in Solution 1 is also excellent - I was going to include it in my answer as well :).
Personally, I turned my back to the built-in keep-alive over 15 years ago. Perhaps I did not have enough experience at the time, perhaps the old versions of Windows did not implement the feature well enough in the TCP stack. In any case, I could not make it work reliably and ever since then, I have implemented my own keep-alive mechanism. I know you didn't really ask about this, but since it sounds like you have control of the code on both the client and the server side, I feel you will be better off implementing your own keep-alive as well.
There are many, many ways of designing this. In the beginning, I would have both sides send keep-alives, the receiver should return an ACK and things like that, but over the years I have found the following approach to be sufficient just about anywhere I use persistent TCP connections.
- Determine which side will be sending data most often. Let's call that side A, the other side is side B. Depending on the nature of your applications, side A can be either the server or the client.
- Determine the maximum time a link can be down before your application should react on it (1 second, 10 seconds, 30 seconds, etc.). Let's call that T. You do not want to flood the network with these messages, so go as high as you can while still being able to react to a link going down as quickly as you need to.
- Define your keep-alive message. It should obviously be pretty small (I tend to have a time stamp in it and nothing else).
While the systems are connected:
- Side A must keep track of the last time it sent a message (data or keep-alive). If more than T/3 seconds have passed since a message was sent, send a keep-alive message. If the link has gone down, the socket send operation will fail and the program has to react to it.
- Side B must keep track of the last time it received a message (data or keep-alive). If more than T seconds have passed since a message was received, consider the link down and react to it.
I feel this is a fairly simple approach and it works great for me.
[EDIT]
Sorry, I didn't see your update before I posted this Solution. I would answer you basic question by saying you should set it on both sides, but I don't think it will solve your problem. If it fails on your local network when you have it configured on one end, it will most likely still fail even if you configure it on both ends.
[/EDIT]
Soren Madsen
Submit an article or tip