winsock的阻塞和非阻塞通信模型

摘要:在应用程序开发中,经常涉及各式各样的机器的交互通信问题。在Windows操作系统下,可以使用MFC中的CSocket,也可以使用以Windows Api为基础的Winsock等等。本文主要描述了Winsock的两种实现方式,即阻塞方式和非阻塞方式。并对应这两种方式,描述了Select模式和IOCP模式。
关键字:Winsock Blocking   NonBlocking   Select模式   完成端口(IOCP)模式
一、Winsock简介
对于众多底层网络协议,Winsock是访问它们的首选接口。而且在每个Win32平台上,Winsock都以不同的形式存在着。Winsock是网络编程接口,而不是协议。在Win32平台上,Winsock接口最终成为一个真正的“与协议无关”接口,尤其是在Winsock 2发布之后。
Win32平台提供的最有用的特征之一是能够同步支持多种不同的网络协议。Windows重定向器保证将网络请求路由到恰当的协议和子系统;但是,有了Winsock,就可以编写可直接使用任何一种协议的网络应用程序了。
在广泛使用的windows平台下,winsock2被简单包装为一组庞大的Api库,通过WSA Start up加载的关于Winsock版本的信息,初始了winsock相关的dll和lib,在成功调用了WSA Startup之后,即可设计自主的与通信有关的行为,当确认了执行完操作后,调用相应的WSA Cleanup,释放对winsock DLL的引用次数。几乎所有在windows平台下可使用的通信框架都是由Winsock扩展而来的。
这里,之所以要再提windows下的winsock Api编程,并不多余,虽然也可以使用CSocket或ACE(ADAPTIVE Communication Environment)框架,但直接对较底层的本地操作系统API,会使我们更深的理解隐藏在框架下的实现,有时也可以解决一些实用问题。
本文涉及的主要是Winsock中面向连接(TCP)部分。
二、阻塞和非阻塞
阻塞socket,又被称为锁定状态的socket。非阻塞socket,又被称为非锁定状态的socket。当调用一个Winsock Api时, Api的调用会耗费一定的CPU时间。当一个操作完成之后才返回到用户态,称其为阻塞,反之,则为非阻塞。当调用Api产生一个基于流协议(TCP)的socket时,系统开辟了接收和发送两个缓冲区,所以操作实际都是用户缓冲区和系统缓冲区的数据交互,并不是实际操作的完成,阻塞也是如此。如果综合被TCP协议默认使用的nagle算法,在数据包(TCP Payload)比较短时,协议可能推迟其发送,就不难想象了。
很多做过Winsock通信的人,都知道非阻塞的socket,也就是异步socket的效率远远高于阻塞socket。可是除了直观的认识外,底层的原理又是什么呢?首先,阻塞的socket的最合理方式是:先知道socket句柄的可读写性,再发起动作。因为如果不做检测而直接发起操作,那么TCP的默认超时将让你后悔不该这么鲁莽。于是,在一次动作中,完成了两次从用户态到系统态的状态转换,异步的socket实际只告诉系统,所期望的操作,而不完成这种操作,系统会对每次提交的操作进行排队。当指定的操作完成时,系统态跳转至用户态。这样,只用了一次状态转换。其次,由于阻塞的特性,它比非阻塞占用了更多的CPU时间。
当然,程序总是要适合需求,有时阻塞的socket亦可满足要求。
三、Select模式
select模式是Winsock中最常见的I/O模型。之所以称其为“select模式”,是由于它的中心思想是利用select函数,实现对I/O的管理。利用select函数,判断套接字上是否存在数据,或者能否向一个套接字写入数据。设计这个函数,唯一的目的是防止应用程序在套接字处于锁定模式中时,在一次I/O绑定调用(如send或recv)过程中,被迫进入“锁定”状态。
对select不再赘述,msdn已经给出了详细的解释。这里要讨论下面两个问题。
1.Select的fd_set数组可承受的最大数
细心的coder可能都注意到了msdn中对FD_SETSIZE(winsock2.h)宏的说明,可以在包含winsock2.h之前重新定义这个宏,它将允许在一个select操作中处理更多的socket句柄(>64)。但是为何定义就是64呢?这不仅是unix的遗留,更是select处理能力的一种衡量标准,过多的socket句柄检测毕竟会影响到对已存在操作的socket的响应。一个最合理的建议是,当程序运行在多CPU的机器上时,可以从逻辑上将socket句柄分为数个组,每组都小于64,用多个线程对每组socket进行select,这样可以增加程序的响应能力。如果是单CPU,则可将FD_SETSIZE增大至256,适当放大timeout。这时每个socket上吞吐量如果还很大,CPU利用率也据高不下,那就要考虑换种模型。
2.Select在多端口侦听中的应用
众所周知,在winsock api中,accept()是一个典型的阻塞操作,通常是建立一个侦听线程来单独执行accept()。如果程序要完成多于一个端口的侦听,自然,建立数个线程也是一个办法,但这里最好使用select。Msdn中解释了这种应用:readfds可以检测出当前listening的socket句柄上是否有有效的connect发生。把本地listening的socket句柄置入readfds,当某个socket有效时,对它调用accept(),此时,发现accept()会立刻成功返回,一个线程就完成了多端口的侦听。
四、非阻塞与完成端口模式
IO完成端口:一种windows独有的异步IO机制。它不专属socketIO,更多的应用是file IO和串口IO。这种模式的优点是:在句柄较多时,较低的CPU利用率和较高的吞吐量。但设计上有较高的复杂性,只有在应用程序需要同时管理数百乃至上千个套接字的时候,并希望随着系统内安装的CPU数量的增多,应用程序的性能也可以线性提升,才应考虑采用“完成端口”模式。
在windows下,IOCP已经可以说是顶级的通信方式了,在网上能搜到的资料都表明:windows的高效通信 =IOCP + 多线程。IOCP server的工作过程如下,代码在windows sdk中。
                主线程 
                    ¦  
  CreateIoCompletionPort                                                                                                                                      ¦                                                                                                     
CreateThread               —————————      完成端口线程  
                                                                                              ¦  
  ¦----   While(TRUE)                                             While(TRUE)----------   ¦  
                   ¦                                                                         ¦                            
             Accept                                             ¦------GetQueuedCompletionStatu s()      ¦  
¦                  ¦                                                 ¦                        ¦                      
¦   CreateIoCompletionPort         ¦                    WsaRev/WsaSend-------   ¦  
¦                  ¦                                                   ¦                        ¦  
¦----WsaRev/WsaSend                                   -------   Windows系统  
                      ¦                                                   ¦     
Windows系统      ---------  
应注意以下两个事项:
(1)当调用WsaRecv和WsaSend,会提供一个WSADATA的数据结构,其中的指针指向的是用户缓冲区,由于以上两个函数在大多数情况下并不是立即就可以完成的,所以,在GetQueuedCompletionStatu s没有收到完成事件前,这个缓冲区不可修改或释放。
(2)经常会在技术论坛中见到有人提问关于IOCP的异步方式会导致乱包的问题。首先看一下IOCP的原理,其实它就相当一个由windows底层管理的有事务功能的消息队列。看过所谓“windows泄漏代码”的人都会注意到windows并不保证这个队列是有序的,特别是当将完成事件通知用户的多个GetQueuedCompletionStatu s线程时,由于调度算法,并不能保证先递交的操作会先返回结果。这样,如果在当前队列中对一个socket句柄有两个recv的待完成操作,此时,socket底层缓冲区内数据为“abcd”,第一个操作完成了“ab”,第二个操作应该完成 “cd”,但第二个操作先找到了空闲线程返回了,于是,数据就乱了。解决的方法很简单,只要从逻辑上保证一个socket句柄接收和发送操作都是同步完成的(即完成一个,才发起下一个),就可以避免乱包。
下面提出两点技巧:
即使在网上能找到关于IOCP的代码,几乎都是照搬了sdk中的实例,在自己编写代码时,还是会碰到更多的问题。
(1)sdk代码中存在一个没有说明的问题。其中模拟的是一个基于一定固有消息的服务器,每收到一包消息,处理后发出一包消息,WsaRecv是常发出的,如果应用突然要发送一包消息呢?由于一个socket只存在一个异步操作使用的WSAOVERLAPPED结构,所以最常见的办法是使用api             PostQueuedCompletionStat us()将一个已投出的WsaRecv“召回”,再投出WsaSend,这样浪费了一次操作,在连接数较大时,这种代价是不可忽略的。更好的办法是使用两个WSAOVERLAPPED结构,我使用的数据结构如下:
     typedef enum _IO_OPERATION
     {
       ClientIoAccept,
       ClientIoRead,
       ClientIoWrite
     } IO_OPERATION, *PIO_OPERATION;
 
     typedef struct _PER_IO_CONTEXT
     {
       WSAOVERLAPPED                             Overlapped;
       char                                               *Buffer;
 
       WSABUF                                           wsabuf;
       IO_OPERATION                               IOOperation;
       SOCKET                                           SocketAccept;
       int                                                 State;
 
       int                                                 nTotalBytes;
       int                                                 nSentBytes;
 
       struct _PER_IO_CONTEXT           *pIOContextForward;
     } PER_IO_CONTEXT, *PPER_IO_CONTEXT;
 
     typedef struct _PER_SOCKET_CONTEXT
     {
     int                                             state;
     SOCKET                                       sock;
     struct   sockaddr_in                   remote;
 
     PPER_IO_CONTEXT                         pRIOContext;
     PPER_IO_CONTEXT                         pSIOContext;
 
     struct _PER_SOCKET_CONTEXT   *pCtxtBack;
     struct _PER_SOCKET_CONTEXT   *pCtxtForward;
     } PER_SOCKET_CONTEXT, *PPER_SOCKET_CONTEXT;
 
 
PER_IO_CONTEXT中包含了一个WSAOVERLAPPED结构,每个socket上下文PER_SOCKET_CONTEXT中包含了两个PER_IO_CONTEXT的指针,这样WsaRecv使用pRIOContext中的WSAOVERLAPPED,而WsaSend使用pSIOContext中的WSAOVERLAPPED,互不干扰。
(2)上述问题解决了,但又带来了一个新的问题。在socket注册入IOCP时,completionkey是PER_SOCKET_CONTEXT的地址。此时,如果在这个socket上有完成事件,completionkey会被返回,但如何知道是接收还是发送完成了呢?你一定会想到WSAOVERLAPPED的地址也不被返回了,和pRIOContext以及pSIOContext中的WSAOVERLAPPED地址比一下就可以了,然而,地址比较是C语言的大忌。其实,上面的数据结构也是在sdk代码上改来的,注意在WsaRecv以及WsaSend中用的Overlapped指针,正是PER_IO_CONTEXT的地址,强制类型转换即可,其中IO_OPERATION正是对操作类型的描述。
五、几点补充
IOCP到底有多高效呢?<<Network   Programming   for   Microsoft   Windows   2nd>>有个技术统计,采用IOCP时:  
Attempted/Connected:   50,000/49,997  
Memory   Used   (KB):   242,272  
Non-Paged   Pool:   148,192  
CPU   Usage:   55–65%  
Threads:   2  
Throughput  (Send/Receive  Bytes  Per  Second):4,326,946/4,326,496  (The  server  was a  Pentium  4  1.7  GHz   Xeon   with  768  MB   memory)
  因此,接受几千个连接是可能的,但要稳定处理就有赖于服务器性能和程序的健壮性。
对自己程序的测试还要注意一些windows特性:
(1)连接测试时,win2k缺省的出站连接的临时端口为1024-5000,要想使用更多的出站端口需要修改注册表,修改方式:  
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\项下建一个MaxUserPort(双字节值),例如:取值为10000时,大约有9000个端口可用。
(2)在intel x86上,非页面内存池仅占物理内存的1/8,windows将socket正是分配在这一区域上,根据“Busy-ness”原则,为每个socket分配的内存将随着socket的使用方式发生变化,但最少在2k以上,overlap也正是在申请非页面内存池,在NT下分块的大小是4k,接收发送共需要8k,这样一个socket大约需要10k的空间。服务器如果有1G内存,那么能支撑的socket数也在12,000左右。所以,所谓接受几万个连接完全不可能。真正这样的需求都是通过集群实现的。
(3)欲知socket的状态,一般要使用iphelper.h中GetTcpTable()实现,当然枚举属性为0x1a的handle也可以实现。
参考文献
[1]<<Network Programming for Microsoft Windows 2nd>>                 Microsoft press
[2]Platform SDK Documentation                                 Microsoft■

你可能感兴趣的:(winsock的阻塞和非阻塞通信模型)