失去连接后尽快断开流式 HTTP 连接
因此，我们想要实现的是维持从移动设备到我们的 Erlang HTTP 服务器的大量并发连接。当然，移动设备可能会有相当间歇性的连接，因此我们希望尽快删除死连接以避免其开销。
现在，我不确定我们应该在什么级别检测死连接。 TCP 有保活数据包，需要 ACK。因此，理想情况下，我们每 15 秒发送一个保活数据包，如果我们在接下来的 15 秒内没有收到 ACK，那么我们就会断开连接。然而，我不知道这在 Erlang 中是否可能。另外，我认为某些 NAT、Wi-Fi 路由器和移动网络可能会在一定时间内确认保持活动，如果我错了，请纠正我。是这样吗？如果是这样，是否有任何 TCP 级别的替代方法来执行“心跳”？
我们还尝试了应用程序级心跳 - 沿 HTTP 流发送 \n。然而，即使设置了所有适用的 Erlang 选项（包括 send_timeout），在某些情况下（例如移动设备距离 Wi-Fi 路由器太远），我们在大约 5 分钟内不会收到任何错误。
我们如何才能最好地实现流式 HTTP 连接，使服务器在失去联系后尽快断开连接？任何帮助将不胜感激！
So what we're trying to achieve is maintaining a vast number of concurrent connections from mobile devices to our Erlang HTTP server. Mobile devices of course can have have pretty intermittent connections, so we're looking to drop dead connections as soon as possible to avoid their overhead.
Now, I'm not sure at what level we should be detecting dead connections. TCP has keepalive packets, which require an ACK. So ideally we'd send a keepalive packet ever 15 seconds, and if we didn't receive the ACK within the next 15 seconds then we'd drop the connection. However, I've no idea if this is even possible in Erlang. Also, I think there's the possibility that some NATs, wi-fi routers and mobile networks are ACKing the keepalives for a certain amount of time, correct me if I'm wrong. Is that the case, and if so is there any TCP-level alternative way of doing 'heartbeats'?
We've also tried an application-level heartbeat - sending a \n down the HTTP stream. However, even with all applicable Erlang options set, including send_timeout, we're not getting any error for about 5 minutes under certain circumstances, such as, say, the mobile device straying too far from its wi-fi router.
How best can we implement a streaming HTTP connection that the server will drop as soon as possible after losing contact? Any help'd be much appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以为 HTTP 连接添加特定的看门狗。看门狗将具有可配置的超时，该超时将在连接上的每次操作（读或写）后重置。如果在指定的超时时间内没有对套接字进行任何操作 - 连接将关闭。
这种方法将消除陈旧连接的问题（连接完全健康但没有任何 I/O 活动）。如果客户端超出覆盖范围，连接将仅持续指定的超时时间。使用看门狗方法时也不需要保持活动机制。
唯一的缺点是服务器不会立即检测到断开的连接，而是等待连接看门狗中指定的超时。
You can add a specific watchdog for HTTP connection. Watchdog will have configurable timeout that will be reset after each operation (read or write) on connection. And if there were no operations on socket within specified timeout - connection is closed.
This approach will eliminate the problem of stale connections (connections perfectly healthy but without any I/O activity). And if clients is out of coverage - connection will last only up to specified timeout. Also no keep-alive mechanism is needed when using watchdog approach.
The only drawback is that server will not detect broken connections immediately but will instead wait timeout specified in connection watchdog.
Isac 的评论为我解答了这个问题 - 在机器级别配置套接字保持活动超时。
请参阅http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive。 html
Isac's comment answered it for me - configuring the socket keep alive timeout at the machine level.
See http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html