请帮我理解windows socket上的keep alive选项 [英] Please help me understand keep alive option on windows sockets
问题描述
大家好。
我创建了一个服务器应用程序，客户端连接到它。我知道我们可以启用keep-alive套接字选项，以便在超时后不会丢弃侦听套接字。 MSDN有一个在侦听套接字（服务器套接字）上设置keep-alive选项的示例，但我的理解是客户端应该向服务器发送保持活动消息，因此在客户端套接字中设置keep-alive选项是很自然的，而不是服务器插座。我很困惑，我不知道是否应该在客户端套接字或服务器套接字中设置keep-alive选项。目前，我在客户端套接字中启用了keep-alive选项，它可以在许多网络中运行，但在某些网络中，例如，我工作的公司中的本地网络，它不起作用，服务器套接字在2小时后被丢弃。服务器ÓS是Windows 2003服务器，客户端是Windows 7.我多次搜索MSDN，但我没理解。
编辑：我的问题就是这个：
我应该在客户端套接字，服务器套接字或两者中设置keep-alive选项吗？
提前感谢
mr.abzadeh
Hello guys.
I have created a server application and clients connect to it. I know that we can enable keep-alive socket option so that the listening socket is not dropped after a timeout. MSDN has an example that sets keep-alive option on listening sockets(server sockets), But my understanding is that the client should send keep-alive messages to server, so it is natural to set keep-alive option in client sockets, not server sockets. I am confused, I don't know if I should set keep-alive option in client sockets, or in server sockets. Currently, I enable keep-alive option in client sockets, and it works in many networks, but In some networks, for example, the local network in the company I work in, it doesnt work and the server socket is dropped after 2 hours. The server ÓS is windows 2003 server, and clients are windows 7. I searched MSDN many times, but I failed to understand it.
My question simply is this:
Should I set keep-alive option in Client socket, Server socket, or Both?
thanks in advance
mr.abzadeh
推荐答案
keepalive的TCP超时默认为2小时。 .NET有一个不同的API，你可以在注册表中设置最多1192小时。
http://blogs.technet.com/b/ nettracer / archive / 2010/06/03 /你可能想知道的东西 - tcp-keepalives.aspx [ ^ ]
阅读本文以了解更多关于keepalive的信息：
http://tools.ietf.org/html/rfc1122#page-101 [ ^ ]
引用：
TCP保持活动机制只应在
服务器应用程序中调用，否则可能会挂起
如果
客户端在网络崩溃或中止连接时无限期地消耗资源
失败。
The TCP timeout for keepalive defaults to 2 hours. .NET has an API to vary this else you can set in the registry to a max of 1192 hours.
http://blogs.technet.com/b/nettracer/archive/2010/06/03/things-that-you-may-want-to-know-about-tcp-keepalives.aspx[^]
Read this to find out more about keepalive:
http://tools.ietf.org/html/rfc1122#page-101[^]
Quote:
"A TCP keep-alive mechanism should only be invoked in
server applications that might otherwise hang
indefinitely and consume resources unnecessarily if a
client crashes or aborts a connection during a network
failure."
此帖子 [< a href =http://social.msdn.microsoft.com/Forums/en-US/d5b6ae25-eac8-4e3d-9782-53059de04628/tcp-keepalive-settings-problem?forum=netfxnetcom\"target =_ blanktitle =新窗口> ^ ]非常有价值，因为它验证了您不是唯一一个遇到此功能问题的人。请允许我引用其中一个要点，因为我认为它与您在本地网络上遇到的问题有关：
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:
这些机制与发送自己的消息几乎完全相同，唯一的区别是数据包包含最少的数据 - return只包含头，所以它可能会被某些路由器切断（不路由） /防火墙的。在大多数项目中，我倾向于最终编写自己的ping机制，因为其他端需要同时知道网络故障（在给定时间间隔内未收到ping消息意味着关闭）。编写自己的机制也可以让您更快地检测它，或者您必须更改发送超时等以符合您的规范。
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.
解决方案1中的链接也非常好 - 我打算将它包含在我的回答:)。
就个人而言，15年前，我背对着内置的保持活力。也许我当时没有足够的经验，也许旧版本的Windows没有在TCP堆栈中很好地实现该功能。无论如何，我无法让它可靠地工作，从那以后，我已经实现了自己的保持活动机制。我知道你并没有真正问过这个问题，但是因为听起来你可以控制客户端和服务器端的代码，我觉得你最好还是实现自己的keep-alive。
有很多种设计方法。一开始，我会让双方都发送保持联系，接收方应该返回ACK等等，但多年来我发现以下方法对于我使用持久TCP连接的任何地方都足够了。
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.
- 确定链接在应用程序响应之前可以关闭的最长时间（1秒，10秒） ，30秒等）。我们称之为 T 。您不希望使用这些消息充斥网络，因此请尽可能高，同时仍能够根据需要尽快对链接做出反应。
- 定义您的保留 - 活着的消息。它显然应该很小（我往往有一个时间戳，没有别的）。
- 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).
< u> 系统连接时：
While the systems are connected:
- Side B 必须跟踪上次收到的时间消息（数据或保持活动）。如果收到消息后超过 T 秒，请考虑关闭链接并对其作出反应。
- 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觉得这是一个相当简单的方法，它对我很有用。
对不起，我在发布此解决方案之前没有看到您的更新。我会回答你的基本问题，说你应该在双方都设置它，但我不认为它会解决你的问题。如果在一端配置它在本地网络上失败，即使你在两端配置它也很可能仍会失败。
[/ EDIT]
Soren Madsen
I feel this is a fairly simple approach and it works great for me.
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
这篇关于请帮我理解windows socket上的keep alive选项的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
