所谓意外断开，是客户端（多指支持3G的移动设备）并没有正常关闭socket，双方并未按照协议上的四次挥手去断开连接，一般的处理办法都是利用保活机制。而保活机制分又可以让底层实现也可自己实现。

一、双方拟定心跳（自实现）

一般由客户端发送心跳包，服务端并不回应心跳，只是定时轮询判断一下与上次的时间间隔是否超时（超时时间自己设定）。服务器并不主动发送是不想增添服务器的通信量，减少压力。

但这会出现三种情况：

情况1.

客户端由于某种网络延迟等原因很久后才发送心跳（它并没有断），这时服务器若利用自身设定的超时判断其已经断开，而后去关闭socket。若客户端有重连机制，则客户端会重新连接。若不确定这种方式是否关闭了原本正常的客户端，则在ShutDown的时候一定要选择send,表示关闭发送通道，服务器还可以接收一下，万一客户端正在发送比较重要的数据呢，是不？

情况2.

客户端很久没传心跳，确实是自身断掉了。在其重启之前，服务端已经判断出其超时，并主动close，则四次挥手成功交互。

情况3.

客户端很久没传心跳，确实是自身断掉了。在其重启之前，服务端的轮询还未判断出其超时，在未主动close的时候该客户端已经重新连接。

这时候若客户端断开的时候发送了FIN包，则服务端将会处于CLOSE_WAIT状态；

这时候若客户端断开的时候未发送FIN包，则服务端处还是显示ESTABLISHED状态；

而新连接上来的客户端（也就是刚才断掉的重新连上来了）在服务端肯定是ESTABLISHED;这时候就有个问题，若利用轮询还未检测出上条旧连接已经超时（这很正常，timer总有个间隔吧），而在这时，客户端又重复的上演情况3，那么服务端将会出现大量的假的ESTABLISHED连接和CLOSE_WAIT连接。

最终结果就是新的其他客户端无法连接上来，但是利用netstat还是能看到一条连接已经建立，并显示ESTABLISHED，但始终无法进入程序代码。个人最初感觉导致这种情况是因为假的ESTABLISHED连接和CLOSE_WAIT连接会占用较大的系统资源，程序无法再次创建连接（因为每次我发现这个问题的时候我只连了10个左右客户端却已经有40多条无效连接）。而最近几天测试却发现有一次程序内只连接了2，3个设备，但是有8条左右的虚连接，此时已经连接不了新客户端了。这时候我就觉得我想错了，不可能这几条连接就占用了大量连接把，如果说几十条还有可能。但是能肯定的是，这个问题的产生绝对是设备在不停的重启，而服务器这边又是简单的轮询，并不能及时处理，暂时还未能解决。

二、利用KeepAlive

在S和C建立连接后，若双方均不发送数据只保持连接，则再两小时后（这个时间我未测试过，但很多资料都显示是这个间隔，貌似是默认的）系统会自动启动保活机制向peer发送包，看对方是否回应ack，若可以收到则继续保持，否则无效。这也就能解释如下现象了：

现象1：

自己写的socket程序放在pc机上（2台），为了模拟意外断掉，将客户端的网线拔掉，点击任何一方去发送都发送不了（这肯定么），那么你认为这时连接已经断了吗？非也，tcp连接并没有断，因为双方还不知道对方是否已经断掉（保活机制还未启动呢），这时若查看netstat，发现状态很已然是ESTABLISHED；当过一段时间后将客户端的网线插好，则可以继续发送。

现象2：

根据现象1的描述，感觉当电脑意外断网的时候，在短时间内又恢复时，QQ的自动连接也应该是这样。

在C#中有关keepalive的资料连MSDN都说的轻秒淡写，如果不是搞C++的还真不知道咋弄，在网上看了很多文章，感谢以下文章的作者：

http://blog.csdn.net/kenkao/article/details/5415159

http://www.cnblogs.com/wzd24/archive/2007/05/22/755050.html

http://blog.csdn.net/kenkao/article/details/5804539

其实实现keepalive在c#里就一句话，但又两种方式：

1.IOControl

          public int IOControl(IOControlCode ioControlCode, byte[] optionInValue, byte[] optionOutValue);
//
// 摘要:
//     使用 System.Net.Sockets.IOControlCode 枚举指定控制代码，为 System.Net.Sockets.Socket
//     设置低级操作模式。
//
// 参数:
//   ioControlCode:
//     一个 System.Net.Sockets.IOControlCode 值，它指定要执行的操作的控制代码。
//
//   optionInValue:
//     System.Byte 类型的数组，包含操作要求的输入数据。
//
//   optionOutValue:
//     System.Byte 类型的数组，包含由操作返回的输出数据。
//
// 返回结果:
//     optionOutValue 参数中的字节数。

无论是看msdn还是这里的注释，都不知道这几个参数是什么意思，在上面的博客中楼主解释了其中的含义：

在C++中第二个参数不是数组而是结构体

struct tcp_keepalive 
{ 
    u_long  onoff; //是否启用Keep-Alive
    u_long  keepalivetime; //多长时间后开始第一次探测（单位：毫秒）
    u_long  keepaliveinterval; //探测时间间隔（单位：毫秒）
}; 

这下就明白了，原来参数是在这里设置的

        

private byte[] GetKeepAliveByte(){uint dummy = 0;byte[] inOptionValues = new byte[Marshal.SizeOf(dummy) * 3];BitConverter.GetBytes((uint)1).CopyTo(inOptionValues, 0);//是否启用Keep-AliveBitConverter.GetBytes((uint)5000).CopyTo(inOptionValues, Marshal.SizeOf(dummy));//多长时间开始第一次探测BitConverter.GetBytes((uint)5000).CopyTo(inOptionValues, Marshal.SizeOf(dummy) * 2);//探测的时间间隔return inOptionValues;}

当然也可以写成有参数的，更好的去调用。

2.SetSocketOption

           public void SetSocketOption(SocketOptionLevel optionLevel, SocketOptionName optionName, byte[] optionValue);

        // 摘要:
//     将指定的 System.Net.Sockets.Socket 选项设置为指定的值，表示为字节数组。
//
// 参数:
//   optionLevel:
//     System.Net.Sockets.SocketOptionLevel 值之一。
//
//   optionName:
//     System.Net.Sockets.SocketOptionName 值之一。
//
//   optionValue:
//     System.Byte 类型的数组，表示选项值。
//

这个方法感觉和上面的调用的都是一样的，我所以我借鉴的第一种。

实现方式：

在accept成功后进行

e.AcceptSocket.IOControl(IOControlCode.KeepAliveValues, GetKeepAliveByte(),null);//开启keepalive机制