客户端连上服务器以后，如果把客户端网线拔了会怎么样？

TCP连接的异常断开情况的讨论：
（假设两个不同主机系统C、D的进程CT,DT存在一个TCP连接）。

1。进程异常终止。
CT异常终止而C正常，TCP连接被C关闭掉并立即告之D,DT会很快得知此TCP连接被异常关闭。在编程时此类异常会在一次Socket调用中得知，程序员可以简单的进行处理。

2。系统异常终止。
这包括主机系统死机，和主机网络硬件断开（比如，拔掉网线）两种情况。假设C系统异常,此时D无法知道此TCP连接的失效，并一直认为连接正常。这种情况在编程时会变的非常糟糕，因为TCP连接将一直被认为有效，所有对此TCP Socket的调用都会正确返回，这显然是错误的。这种错误情况通常会持续很久，即便是设置了Socket的SO_KEEPALIVE属性，默认情况也要等上2个小时。如果DT是FTP之类的服务器程序倒也无妨（一个连接存在2个小时对它没有多大影响），如果是需要实时知道连接用户状态的即时通讯类服务器则就成问题了。
前者的问题并不一定需要解决，后者的解决方法一般是服务器程序和客户端程序达成某种协议，客户端定时向服务器发送很小的数据包（记为‘在线状态更新’）来告诉自己的状态，而服务器端程序则需要在每次收到用户的‘在线状态更新’后更新用户超时的时间计数，当用户的时间计数超过指定时间，就可以认为这个用户已经‘系统异常终止’，而终止之间的连接，并转告其他用户。
再讨论一下CT，在系统死机时CT肯定也死了也就没有处理的必要，在网络硬件断开情况下它的形势和DT一样，它也会等，处理方法也可以采用DT的处理方法。

3.如果网线断开的时间短暂，在SO_KEEPALIVE设定的探测时间间隔内，并且两端在此期间没有任何针对此长连接的网络操作。当连上网线后此TCP连接可以自动恢复，继续进行正常的网络操作。

如果网线断开的时间很长，超出了SO_KEEPALIVE设定的探测时间间隔，或者两端期间在此有了任何针对此长连接的网络操作。当连上网线时就会出现ETIMEDOUT或者ECONNRESET的错误。你必须重新建立一个新的长连接进行网络操作。

游戏服务器常常有心跳包的设计。我们的心跳包就是为了防止Socket断开连接，或是TCP的连接断开吗？答案是否定的，TCP连接的通道是个虚拟的，连接的维持靠的是两端TCP软件对连接状态的维护。TCP 连接自身有维护连接的机制，说白了就是自身有长时间没有数据包情况下的判断连接是否还存在的检测，清除死连接，即使在没有数据来往的时候，TCP也就可以（在启动TCP这个功能的前提下）自动发包检测是否连接正常，这个不需要我们处理。服务端设计心跳包的目的：探知对端应用是否存活，服务端客户端都可以发心跳包，一般都是客户端发送心跳包，服务端用于判断客户端是否在线，从而对服务端内存缓存数据进行清理（玩家下线等）；问题在于，通过TCP四次握手断开的设定，我们也是可以通过Socket的read方法来判断TCP连接是否断开，从而做出相应的清理内存动作，那么为什么我们还需要使用客户端发送心跳包来判断呢？第一种判断客户端是否在线策略:直接监控TCP传输协议的返回值，通过返回值处理应用层的存活判断比如在C++当中使用poll的IO复用方法时：if(fds[i].revents & POLLERR) if(fds[i].events & POLLDHUP)通过上述判断可以探知TCP连接的正确性从而在服务器也关闭对应的连接close() on the file descriptor will release resources that are still being reserved on behalf of the socket. 此时调用close()函数才会释放相关的资源。比如说进行如下处理：/*

//如果客户端关闭连接，则服务器也关闭对应的连接，并将用户总数减1
users[fds[i].fd] = users[fds[user_counter].fd];
close(fds[i].fd);
fds