那网络异常断开原因主要有那些呢?归纳起来主要有以下两种:
1、客户端程序异常。
对于这种情况,我们很好处理,因为客户端程序异常退出会在服务端引发connectionreset的socket异常(就是winsock2中的10054异常)。只要在服务端处理这个异常就可以了。
2、网络链路异常。
如:网线拔出、交换机掉电、客户端机器掉电。当出现这些情况的时候服务端不会出现任何异常。这样的话上面的代码就不能处理这种情况了。对于这种情况在msdn里面是这样处理的,我在这里贴出msdn的原文:
如果您需要确定连接的当前状态,请进行非阻止、零字节的 send 调用。如果该调用成功返回或引发 waewouldblock 错误代码 (10035),则该套接字仍然处于连接状态;否则,该套接字不再处于连接状态。
但是我在实际应用中发现,msdn说的这种处理方法在很多时候根本无效,无法检测出网络已经异常断开了。那我们该怎么办呢?
我们知道,tcp有一个连接检测机制,就是如果在指定的时间内(一般为2个小时)没有数据传送,会给对端发送一个keep-alive数据报,使用的序列号是曾经发出的最后一个报文的最后一个字节的序列号,对端如果收到这个数据,回送一个tcp的ack,确认这个字节已经收到,这样就知道此连接没有被断开。如果一段时间没有收到对方的响应,会进行重试,重试几次后,向对端发一个reset,然后将连接断掉。
在windows中,第一次探测是在最后一次数据发送的两个小时,然后每隔1秒探测一次,一共探测5次,如果5次都没有收到回应的话,就会断开这个连接。但两个小时对于我们的项目来说显然太长了。我们必须缩短这个时间。那么我们该如何做呢?我要利用socket类的iocontrol()函数。我们来看看这个函数能干些什么:
使用 iocontrolcode 枚举指定控制代码,为 socket 设置低级操作模式。 
命名空间:system.net.sockets 
程序集:system(在 system.dll 中) 
语法 
c# 
public int iocontrol ( 
iocontrolcode iocontrolcode, 
byte[] optioninvalue, 
byte[] optionoutvalue 
) 
参数 
iocontrolcode 
一个 iocontrolcode 值,它指定要执行的操作的控制代码。 
optioninvalue 
byte 类型的数组,包含操作要求的输入数据。 
optionoutvalue 
byte 类型的数组,包含由操作返回的输出数据。 
返回值 
optionoutvalue 参数中的字节数。 
如:
 socket.iocontrol(iocontrolcode.keepalivevalues, inoptionvalues, null);
socket.iocontrol(iocontrolcode.keepalivevalues, inoptionvalues, null);
新闻热点
疑难解答