我一直在用C语言进行基本的客户端/服务器通信，我正在尝试确定检测断开连接的客户端的最佳方法。我知道如果我想要一个阻塞解决方案，我可以简单地分支read（）。但是，在非阻塞环境中，特别是在网络中断而不是干净断开的情况下，read（）是否仍会及时检测到断开的连接？
现在我只是在一段时间内从客户端发送保持活动消息并检查服务器端超时，我想知道是否有更清洁的方式。
答案 0 :(得分：1)
无论阻塞模式如何，如果对等体由于任何原因断开连接，则一系列TCP send()操作最终将失败并显示ECONNRESET，并且TCP recv()将返回零，如果同伴断断续续地断开了。
答案 1 :(得分：-1)
一般来说，你不能肯定地检测到一个不干净的客户。
编辑：也就是说，没有通用are_you_still_there()功能，并且没有办法实现一个你可以依赖的快速交付＆＃34; no＆＃34;没有漏报和误报的回复。
如果您使用的是无连接网络协议（即UDP），则您无法肯定地检测到客户端已完全消失。
编辑：TCP在接收方未确认收到的情况下提供自动数据重传。可以进行相同数据的多次重传，在这种情况下，（重新）传输之间的超时呈指数增长。在没有确认的情况下达到阈值数量的重传或阈值重传超时后，TCP子系统将认为连接断开，但这可能需要几个甚至几十分钟，具体取决于本地协议实现和参数。
如果TCP实现通过超时或远程对等方强制切断连接检测到连接中断，则可以依赖read()来发出错误信号。然而，确保将这样的错误以及时的方式传递给应用程序可能是棘手的或不可能的。如果你的概念是及时的＆＃34;与TCP实施有很大不同。
通常通过使用[ edit：application-level ]超时来判断何时释放专用于服务客户端的资源，或者可能通过提供服务的更高级别协议来处理此问题心跳信号或等效信号（基本上仍然归结为超时）。
编辑添加：＆＃34;的实施，你在那里＆＃34;应用层协议中的消息可以提供从对等体请求响应的手段，以便能够在连接否则将是空闲的时间期间测量超时和/或检测连接闭合。因为这或多或少相当于本地机器从远程同伴那里征求心跳的手段，它与您已有的相似。
另一方面，它确实提供了一个框架，其中本地机器可以尝试向对等方发送未经请求的消息而不会干扰应用程序。这样，如果TCP实现标记了连接已关闭，无论是因为TCP级别超时还是因为另一端关闭了它，那么本地机器将在那时通知关闭。