具有 TCP 的持久双工,无需任何 KeepAlive() 方法
我需要为事件通知实现持久的 TCP 双工连接。客户端注册事件,服务器将该事件通知给所有订阅者。
问题是,TCP 连接在 10 分钟后关闭。我知道可靠会话。关闭和不活动超时。
我需要的是在客户端和服务器之间实现某种“始终打开的连接”。客户端一旦发现连接丢失,就会立即重新连接。但在使用 TCP 连接时很难注意到某些连接丢失。
我能够发明某种具有长接收和不活动超时的解决方案。客户端会在较短的时间间隔内“脉冲检查”服务器是否仍然在线并使用某种 KeepAlive() 方法进行连接。
我希望在我的服务合同中没有 KeepAlive() 方法的情况下获得解决方案。
有什么想法吗?
//米罗
I need to implement a long lasting TCP duplex connection for event notification. Client register for events and server informs about this events to all subscribers.
The problem is, the TCP connection closes after 10 minutes. I know about reliable session. close and inactivity timeouts.
What i need is to implement some kind of "always opened connection" between the client and the server. The client reconnects as soon as it notices the connection is lost. but it can be difficult to notice some connection loses while connected with TCP.
I was able to invent some kind of solution with long receive and inactivity timeouts. Client "pulse checks" the server in some short interval, if it's still online and connected using some kind of KeepAlive() method.
I would like to have the solution without having KeepAlive() method on my service contract.
Any ideas?
//Miro
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
TCP 连接不会自行关闭;它们要么被明确关闭,要么其中一个端点已经消失。 (注意:端点可以是中间的透明代理或有状态路由器。)我经常运行 TCP 连接,即使不是保持活动状态,也可以保持数天甚至数月。
对于前者,明确的关闭将通知您的一方,但听起来这并没有发生。
在端点消失的情况下,发送数据是查明对方是否已消失的唯一方法,而保持活动状态是做到这一点的透明方法。
如果您不想使用 TCP 的保持活动状态,那么您需要定期向服务器发送真实数据,或者找出从客户端到服务器的路径上是什么导致连接断开。
TCP connections do not close on their own; they're either explicitly closed or one of the end-points has vanished. (Note: An end-point can be a transparent proxy or stateful router in the middle.) I frequently run TCP connections that stay up for days, if not months, even with no keep-alive.
In the case of the former, an explicit close will get your side notified but it sounds like that isn't happening.
In the case of a vanished end-point, sending data is the only way to find out if the other side has gone away, and keep-alive is the transparent way to do that.
If you don't want to use TCP's keep-alive, then you need to send real data to the server on a periodic basis or find out what along your route from client to server is causing your connection to drop.