异步套接字和“静默"断线 [英] Asyncsockets and "silent" disconnections

问题描述

我一直在使用 cocoaasyncsocket 作为使用 asyncsocket 的 Windows .net 服务器的客户端.我正在使用 ProtocolBuffers 对消息进行编码.这些共同构成了一套很棒的工具.

I've been using cocoaasyncsocket as a client to a Windows .net server using asyncsocket. I am encoding messages using ProtocolBuffers. Together, these make a great set of tools.

但是最近我注意到，如果我让客户端长时间连接到服务器 - 很多小时 - 当我尝试请求数据时，消息似乎已发送但从未到达服务器.我将此称为无声"断开连接，因为我没有收到通常出现网络问题时断开连接的情况.

However recently I have noticed that if I leave the client connected to the server for a long time - many hours - when I try to make a request for data, the message appears to get sent but never arrives at the server. I'm calling this a "silent" disconnection because I'm not receiving the usual disconnection that I would if there were a network problem.

我正在努力调试以下方法，但没有一个被调用:

I am handling the following methods in my effort to debug, but none of them get called:

- (NSTimeInterval)onSocket:(AsyncSocket *)sock
  shouldTimeoutReadWithTag:(long)tag
                   elapsed:(NSTimeInterval)elapsed
                 bytesDone:(CFIndex)length {

- (void)onSocket:(AsyncSocket *)sock willDisconnectWithError:(NSError *)err

- (void)onSocketDidDisconnect:(AsyncSocket *)sock

在没有任何通知的情况下，我发现调试起来很棘手.服务器同样没有显示任何断开连接.

Without any notification, I'm finding this tricky to debug. The server similarly does not show any disconnections.

有人能指出我如何进一步分析这一点的方向吗?

Would anyone be able to point me in a direction to how to further analyze this?

非常感谢.

推荐答案

如果你想知道你的客户端和服务器是连接的，你必须有一个心跳或者keepalive"，即一个应用级的消息，基本上是说你在吗"/是".

If you want to know that your clients and servers are connected, you must have a heartbeat or "keepalive", i.e. an application level message which is exchanged basically saying "Are you there"/"yes".

现在尤其如此，因为许多路由器会默默地丢弃空闲的 TCP 连接.这不是 TCP 的设计目的，但它是生活中的事实.

This is particularly true nowadays as many routers will silently drop idle TCP connections. That's not what TCP was designed for, but it is a fact of life.

TCP 可以选择使用 SO_KEEPALIVE 发送连接层心跳或保持连接，但历史上存在关于这是否合适的争论.设计人员认为由于临时中间网络问题而丢弃套接字是错误的.如果在此期间没有实际发送数据，则没有理由断开连接.其他人则认为，了解连接是否良好本身就很重要.如果您期待数据但尚未到达怎么办?你不想知道吗?

TCP has an option to send connection-layer heartbeat or keepalive with SO_KEEPALIVE, but historically there was an argument over whether this was appropriate. The designers felt that dropping a socket because of a temporary intermediate network problem was wrong. If no data was actually sent during that period, there was no reason to drop the connection. Others felt that knowing whether the connection was good was important in and of itself. What if you were expecting data but it hadn't arrived? Woudln't you want to know?

最终取决于应用程序.如果没有新信息"是对您的应用程序很重要的事实断言(例如新闻提要、销售订单、市场数据价格变化)，您需要检查没有新信息"是否是真正的没有新信息"" 不是 "连接悄悄断开".这意味着一个明确的消息.

Ultimately it depends on the application. If "no new information" is an assertion of fact which is important to your application, (for example news feeds, sales orders, market data price changes) you need to check that the "no new information" is a real "no new information" not a "connection silently dropped". That means an explicit message.

那么您应该多久发送一次?

So how often should you send it?

这取决于事物的平衡.1a) 您通常多久收到一次更新?1b) 可接受/正常的延迟时间(例如，如果这是流程的一部分，其他步骤通常需要数小时，那么 5-10 分钟可能是可以接受的).2a) 电池和 2b) 由于心跳造成的数据使用.我怀疑对电池/功率的影响将是至关重要的，但所有这些都需要仔细查看并平衡.

That depends on a balance of things. 1a) how often do you normally get updates? 1b) What latency is acceptable/normal (e.g. if this is part of a process, other steps take typically hours, then 5-10 minutes might be acceptable). 2a) battery and 2b) data usage due to heartbeat. I suspect the effect on battery/power will be crucial, but all these need to be looked at carefully, and balanced.

毕竟您随时可能失去覆盖范围(隧道等).只有在平均更新间隔的 0.5 到 5 倍之间没有更新时，我才会运行心跳.因此，如果您期望每分钟 2 次更新，则在空闲 15 秒到 3 分钟时运行心跳 - 判断什么是最好的.如果用户在应用程序中实时"并在完成后将其关闭"，则电池寿命不是这样的问题，因为他们无论如何都在使用它.如果您要唤醒设备来处理更新，电池寿命确实是一个问题.

You could lose coverage at any time after all (tunnels etc). I would run the heartbeat only if you have had no updates after something between 0.5 and 5 times the average update interval. So if you expect 2 updates per minute, run heartbeats if idle for 15 seconds to 3 minutes - judge what is best. Provided the user is in the app "live" and "turns it off" when done, the battery life is not such an issue since they are using it anyway. Battery life is really an issue if you are waking the device to process the updates.

这篇关于异步套接字和“静默"断线的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！