与WCF和TCP保持？ [英] KeepAlive with WCF and TCP?
问题描述
我有一个Windows服务托管在TCP（netTCP）与protobuf.net还通信，有时使用证书先进的WCF服务。
I have a Windows Service hosting an advanced WCF service that communicates over TCP(netTCP) with protobuf.net, some times also with certificates.
receiveTimeout 设置为无限永远不会下降由于不活动的连接。但是从我了解的连接，所以我创建了一个简单的双向的存活服务方法的客户端调用每9分钟，以保持连接可无论如何下降。这是非常重要的连接从未中断。
The receiveTimeout is set to infinite to never drop the connection due to inactivity. But from what I understand the connection could be dropped anyway so I have created a simple two way keepalive service method that the client is calling every 9 min to keep the connection alive. It's very important that the connection never breaks.
这是正确的方法是什么？ ？或者，我可以简单地删除我守住，因为在 receiveTimout 设置为无限
Is this the correct way? Or could I simply remove my keep live because the receiveTimout is set to infinite?
编辑：为WCF服务当前的app.config：<一HREF =http://1drv.ms/1uEVKIt相对=nofollow> http://1drv.ms/1uEVKIt
Edit : Current app.config for WCF service : http://1drv.ms/1uEVKIt
推荐答案
没有。这是被广泛误解，不幸的是有很多误传那里。
No. This is widely misunderstood, and unfortunately there is much misinformation out there.
首先，无限是一种半有效值。还有就是是转换无限两个特殊的配置串行或者 TimeSpan.MaxValue 或 int.MaxValue （所以他们又不是真的无限反正），但在WCF不是一切似乎认识到这一点。所以它总是最好与时间值显式指定超时。
First, "Infinite" is a sort of semi-valid value. There is are two special config serializers that convert "Infinite" to either TimeSpan.MaxValue or int.MaxValue (so they're not really "infinite" anyways), but not everything in WCF seems to recognize this. So it's always best to specify your timeouts explicitly with time values.
二，你不需要在服务保活的方法，因为WCF提供了什么叫做可靠的会话。如果添加<启用的ReliableSession =真/> 则WCF将提供它自己的保活机制，通过基础信息
Second, you don't need a "keepalive" method in your service, since WCF provides what's called a "reliable session". If you add <reliableSession enabled="true" /> then WCF will provide it's own keep alive mechanism through "infrastructure messages".
通过拥有自己的保活的机制，你提高了一倍您的服务的负荷，比它解决的你其实可以创造更多的问题。
By having your own "keepalive" mechanism, you're effectively doubling the load on your service and you can actually create more problems than it solves.
三，使用可靠的会话时，您可以使用的ReliableSession <的 inactivityTimeout 设置/ code>。这做了两件事。第一，它控制的基础设施（保活）消息如何频繁地发送。他们一半的超时值发送的，所以如果你把它设置为18分钟，那么他们将被每9分钟发送一次。其次，如果没有基础设施或操作消息（即是你的数据契约的一部分，消息）的非活动超时时间内收到的连接被中止，因为有可能已经被（一侧已崩溃的问题，有一个网络问题，等等。 ）。
Third, when using a reliable session, you use the inactivityTimeout setting of reliableSession. This does two things. First, it controls how frequently infrastructure (keepalive) messages are sent. They are sent at half the timeout value, so if you set it to 18 minutes, then they will be sent every 9 minutes. Secondly, if no infrastructure or operation messages (ie messages that are part of your data contract) are received within the inactivity timeout, the connection is aborted because there has likely been a problem (one side has crashed, there's a network problem, etc..).
receiveTimeout 是没有操作的消息可以前的连接接收的最大时间量中止（默认为10分钟）。此设置为一个较大的值（ TimeSpan.MaxValue 在24天附近某处）保持连接起来上涨，inactivityTimeout设置为较小的值（再次，默认为10分钟）（以时间比两倍的时间最高数额的网络路由器将丢弃从活动的连接）保持活着连接较小。
receiveTimeout is the maximum amount of time in which no operation messages can be received before the connection is aborted (the default is 10 minutes). Setting this to a large value (TimeSpan.MaxValue is somewhere in the vicinity of 24 days) keeps the connection tacked up, setting inactivityTimeout to a smaller value (again, the default is 10 minutes) (to a time that is smaller than 2x the maximum amount of time before network routers will drop a connection from inactivity) keeps the connection alive.
WCF处理所有这个给你。然后，您可以简单地订阅连接异常中止的消息，知道什么时候该连接被丢弃的真正原因（应用程序崩溃，网络超时，客户失去权力，等..），并允许您重新连接。
WCF handles all this for you. You can then simply subscribe to the Connection Aborted messages to know when the connection is dropped for real reasons (app crashes, network timeouts, clients losing power, etc..) and allows you to recreate the connections.
此外，如果你不需要有序消息，请将 =下令假，因为这大大降低了可靠的会话的开销。默认值是true
Additionally, if you don't need ordered messages, set ordered="false", as this greatly reduces the overhead of reliable sessions. The default is true.
请注意：直到inactivityTimeout已过期，您可能不会收到连接中断事件（或您尝试使用该连接）。意识到这一点，并设置相应的超时。
Note: You may not receive a connection aborted event until the inactivityTimeout has expired (or you try to use the connection). Be aware of this, and set your timeouts accordingly.
Internet上的大多数建议是既receiveTimeout和inactivityTimeout设置为无穷大。这有两个问题，一是基础设施的消息不及时被发送，那么路由器将丢弃连接...强迫你做你自己保持连接。其次，大型活动超时是指当一个连接合法丢弃它不会承认，你必须依靠上平中止发生故障时就知道了。这一切完全不必要的，其实是可以甚至让你的服务更是不可靠的。
Most recommendations on the internet are to set both receiveTimeout and inactivityTimeout to Infinite. This has two problems, first infrastructure messages don't get sent in a timely manner, so routers will drop the connection... forcing you to do your own keepalives. Second, the large inactivity timeout means it won't recognize when a connection legitimately drops, and you have to rely on on that ping aborting to know when a failure occurs. This is all completely unnecessary, and can in fact even make your service even more unreliable.
这篇关于与WCF和TCP保持？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
