C++大规模应用程序开发之winsock.docx
《C++大规模应用程序开发之winsock.docx》由会员分享，可在线阅读，更多相关《C++大规模应用程序开发之winsock.docx（11页珍藏版）》请在冰豆网上搜索。
C++大规模应用程序开发之winsock
C++I/O完成端口开发大响应规模的Winsock应用程序
通常要开发网络应用程序并不是一件轻松的事情，不过，实际上只要掌握几个关键的原则也就可以了——创建和连接一个套接字，尝试进行连接，然后收发数据。
真正难的是要写出一个可以接纳少则一个，多则数如果在没有事先获得函数指针的情况下直接调用函数（也就是说，编译时静态连接mswsock.lib，在程序中直接调用函数），那么性能将很受影响。
因为AcceptEx（）被置于Winsock2架构之外，每次调用时它都被迫通过WSAIoctl（）取得函数指针。
要避免这种性能损失，需要使用这些API的应用程序应该通过调用WSAIoctl（）直接从底层的提供者那里取得函数的指针。
参见下图套接字架构：
TransmitFile和TransmitPackets
Winsock提供两个专门为文件和内存数据传输进行了优化的函数。
其中TransmitFile（）这个API函数在WindowsNT4.0和Windows2000上都可以使用，而TransmitPackets（）则将在未来版本的Windows中实现。
TransmitFile（）用来把文件内容通过Winsock进行传输。
通常发送文件的做法是，先调用CreateFile（）打开一个文件，然后不断循环调用ReadFile（）和WSASend（）直至数据发送完毕。
但是这种方法很没有效率，因为每次调用ReadFile（）和WSASend（）都会涉及一次从用户模式到内核模式的转换。
如果换成TransmitFile（），那么只需要给它一个已打开文件的句柄和要发送的字节数，而所涉及的模式转换操作将只在调用CreateFile（）打开文件时发生一次，然后TransmitFile（）时再发生一次。
这样效率就高多了。
TransmitPackets（）比TransmitFile（）更进一步，它允许用户只调用一次就可以发送指定的多个文件和内存缓冲区。
函数原型如下：
BOOLTransmitPackets（
SOCKEThSocket,
LPTRANSMIT_PACKET_ELEMENTlpPacketArray,
DWORDnElementCount,
DWORDnSendSize,
LPOVERLAPPEDlpOverlapped,
DWORDdwFlags
）;其中，lpPacketArray是一个结构的数组，其中的每个元素既可以是一个文件句柄或者内存缓冲区，该结构定义如下：
typedefstruct_TRANSMIT_PACKETS_ELEMENT{
DWORDdwElFlags;
DWORDcLength;
union{
struct{
LARGE_INTEGERnFileOffset;
HANDLEhFile;
};
PVOIDpBuffer;
};
}TRANSMIT_FILE_BUFFERS;
其中各字段是自描述型的（selfexplanatory）。
dwElFlags字段：
指定当前元素是一个文件句柄还是内存缓冲区（分别通过常量TF_ELEMENT_FILE和TF_ELEMENT_MEMORY指定）；
cLength字段：
指定将从数据源发送的字节数（如果是文件，这个字段值为0表示发送整个文件）；
千个连接的网络应用程序。
本文将讨论如何通过Winsock2在WindowsNT和Windows2000上开发高扩展能力的Winsock应用程序。
文章主要的焦点在客户机/服务器模型的服务器这一方，当然，其中的许多要点对模型的双方都适用。
API与响应规模
通过Win32的重叠I/O机制，应用程序可以提请一项I/O操作，重叠的操作请求在后台完成，而同一时间提请操作的线程去做其他的事情。
等重叠操作完成后线程收到有关的通知。
这种机制对那些耗时的操作而言特别有用。
不过，像Windows3.1上的WSAAsyncSelect（）及Unix下的select（）那样的函数虽然易于使用，但是它们不能满足响应规模的需要。
而完成端口机制是针对操作系统内部进行了优化，在WindowsNT和Windows2000上，使用了完成端口的重叠I/O机制才能够真正扩大系统的响应规模。
完成端口
一个完成端口其实就是一个通知队列，由操作系统把已经完成的重叠I/O请求的通知放入其中。
当某项I/O操作一旦完成，某个可以对该操作结果进行处理的工作者线程就会收到一则通知。
而套接字在被创建后，可以在任何时候与某个完成端口进行关联。
通常情况下，我们会在应用程序中创建一定数量的工作者线程来处理这些通知。
线程数量取决于应用程序的特定需要。
理想的情况是，线程数量等于处理器的数量，不过这也要求任何线程都不应该执行诸如同步读写、等待事件通知等阻塞型的操作，以免线程阻塞。
每个线程都将分到一定的CPU时间，在此期间该线程可以运行，然后另一个线程将分到一个时间片并开始执行。
如果某个线程执行了阻塞型的操作，操作系统将剥夺其未使用的剩余时间片并让其它线程开始执行。
也就是说，前一个线程没有充分使用其时间片，当发生这样的情况时，应用程序应该准备其它线程来充分利用这些时间片。
完成端口的使用分为两步。
首先创建完成端口，如以下代码所示：
HANDLEhIocp;
hIocp=CreateIoCompletionPort（
INVALID_HANDLE_VALUE,
NULL,
（ULONG_PTR）0,
0）;
if（hIocp==NULL）{
//Error
}
完成端口创建后，要把将使用该完成端口的套接字与之关联起来。
方法是再次调用CreateIoCompletionPort（）函数，第一个参数FileHandle设为套接字的句柄，第二个参数ExistingCompletionPort设为刚刚创建的那个完成端口的句柄。
以下代码创建了一个套接字，并把它和前面创建的完成端口关联起来：
SOCKETs;
s=socket（AF_INET,SOCK_STREAM,0）;
if（s==INVALID_SOCKET）{
//Error
if（CreateIoCompletionPort（（HANDLE）s,
hIocp,
（ULONG_PTR）0,
0）==NULL）
{
//Error
}
...
}
这时就完成了套接字与完成端口的关联操作。
在这个套接字上进行的任何重叠操作都将通过完成端口发出完成通知。
注意，CreateIoCompletionPort（）函数中的第三个参数用来设置一个与该套接字相关的“完成键（completionkey）”（译者注：
完成键可以是任何数据类型）。
每当完成通知到来时，应用程序可以读取相应的完成键，因此，完成键可用来给套接字传递一些背景信息。
在创建了完成端口、将一个或多个套接字与之相关联之后，我们就要创建若干个线程来处理完成通知。
这些线程不断循环调用GetQueuedCompletionStatus（）函数并返回完成通知。
下面，我们先来看看应用程序如何跟踪这些重叠操作。
当应用程序调用一个重叠操作函数时，要把指向一个overlapped结构的指针包括在其参数中。
当操作完成后，我们可以通过GetQueuedCompletionStatus（）函数中拿回这个指针。
不过，单是根据这个指针所指向的overlapped结构，应用程序并不能分辨究竟完成的是哪个操作。
要实现对操作的跟踪，你可以自己定义一个OVERLAPPED结构，在其中加入所需的跟踪信息。
无论何时调用重叠操作函数时，总是会通过其lpOverlapped参数传递一个OVERLAPPEDPLUS结构（例如WSASend、WSARecv等函数）。
这就允许你为每一个重叠调用操作设置某些操作状态信息，当操作结束后，你可以通过GetQueuedCompletionStatus（）函数获得你自定义结构的指针。
注意OVERLAPPED字段不要求一定是这个扩展后的结构的第一个字段。
当得到了指向OVERLAPPED结构的指针以后，可以用CONTAINING_RECORD宏取出其中指向扩展结构的指针。
OVERLAPPED结构的定义如下：
typedefstruct_OVERLAPPEDPLUS{
OVERLAPPEDol;
SOCKETs,sclient;
intOpCode;
WSABUFwbuf;
DWORDdwBytes,dwFlags;
//其它有用的信息
}OVERLAPPEDPLUS;
#defineOP_READ0
#defineOP_WRITE1
#defineOP_ACCEPT2
下面让我们来看看工作者线程的情况。
工作线程WorkerThread代码：
DWORDWINAPIWorkerThread（LPVOIDlpParam）
{
ULONG_PTR*PerHandleKey;
OVERLAPPED*Overlap;
OVERLAPPEDPLUS*OverlapPlus,
*newolp;
DWORDdwBytesXfered;
while
（1）
{
ret=GetQueuedCompletionStatus（
hIocp,
&dwBytesXfered,
（PULONG_PTR）&PerHandleKey,
&Overlap,
INFINITE）;
if（ret==0）
{
//Operationfailed
continue;
}
OverlapPlus=CONTAINING_RECORD（Overlap,OVERLAPPEDPLUS,ol）;
switch（OverlapPlus->OpCode）
{
caseOP_ACCEPT:
//ClientsocketiscontainedinOverlapPlus.sclient
//Addclienttocompletionport
CreateIoCompletionPort（
（HANDLE）OverlapPlus->sclient,
hIocp,
（ULONG_PTR）0,
0）;
//NeedanewOVERLAPPEDPLUSstructure
//forthenewlyacceptedsocket.Perhaps
//keepalookasidelistoffreestructures.
newolp=AllocateOverlappedPlus（）;
if（!
newolp）
{
//Error
}
newolp->s=OverlapPlus->sclient;
newolp->OpCode=OP_READ;
//Thisfunctionpreparesthedatatobesent
PrepareSendBuffer（&newolp->wbuf）;
ret=WSASend（
newolp->s,
&newolp->wbuf,
1,
&newolp->dwBytes,
0,
&newolp.ol,
NULL）;
if（ret==SOCKET_ERROR）
{
if（WSAGetLastError（）!
=WSA_IO_PENDING）
{
//Error
}
}
//Putstructureinlookasidelistforlateruse
FreeOverlappedPlus（OverlapPlus）;
//SignalacceptthreadtoissueanotherAcceptEx
SetEvent（hAcceptThread）;
break;
caseOP_READ:
//Processthedataread
//...
//Repostthereadifnecessary,reusingthesame
//receivebufferasbefore
memset（&OverlapPlus->ol,0,sizeof（OVERLAPPED））;
ret=WSARecv（
OverlapPlus->s,
&OverlapPlus->wbuf,
1,
&OverlapPlus->dwBytes,
&OverlapPlus->dwFlags,
&OverlapPlus->ol,
NULL）;
if（ret==SOCKET_ERROR）
{
if（WSAGetLastError（）!
=WSA_IO_PENDING）
{
//Error
}
}
break;
caseOP_WRITE:
//Processthedatasent,etc.
break;
}//switch
}//while
}//WorkerThread
其中每句柄键（PerHandleKey）变量的内容，是在把完成端口与套接字进行关联时所设置的完成键参数；Overlap参数返回的是一个指向发出重叠操作时所使用的那个OVERLAPPEDPLUS结构的指针。
要记住，如果重叠操作调用失败时（也就是说，返回值是SOCKET_ERROR，并且错误原因不是WSA_IO_PENDING），那么完成端口将不会收到任何完成通知。
如果重叠操作调用成功，或者发生原因是WSA_IO_PENDING的错误时，完成端口将总是能够收到完成通知。
WindowsNT和Windows2000的套接字架构
对于开发大响应规模的Winsock应用程序而言，对WindowsNT和Windows2000的套接字架构有基本的了解是很有帮助的。
下图是Windows2000中的Winsock架构：
与其它类型操作系统不同，WindowsNT和Windows2000的传输协议没有一种风格像套接字那样的、可以和应用程序直接交谈的界面，而是采用了一种更为底层的API，叫做传输驱动程序界面（TransportDriverInterface,TDI）。
Winsock的核心模式驱动程序负责连接和缓冲区管理，以便向应用程序提供套接字仿真（在AFD.SYS文件中实现），同时负责与底层传输驱动程序对话。
谁来负责管理缓冲区？
正如上面所说的，应用程序通过Winsock来和传输协议驱动程序交谈，而AFD.SYS负责为应用程序进行缓冲区管理。
也就是说，当应用程序调用send（）或WSASend（）函数来发送数据时，AFD.SYS将把数据拷贝进它自己的内部缓冲区（取决于SO_SNDBUF设定值），然后send（）或WSASend（）函数立即返回。
也可以这么说，AFD.SYS在后台负责把数据发送出去。
不过，如果应用程序要求发出的数据超过了SO_SNDBUF设定的缓冲区大小，那么WSASend（）函数会阻塞，直至所有数据发送完毕。
从远程客户端接收数据的情况也类似。
只要不用从应用程序那里接收大量的数据，而且没有超出SO_RCVBUF设定的值，AFD.SYS将把数据先拷贝到其内部缓冲区中。
当应用程序调用recv（）或WSARecv（）函数时，数据将从内部缓冲拷贝到应用程序提供的缓冲区。
多数情况下，这样的架构运行良好，特别在是应用程序采用传统的套接字下非重叠的send（）和receive（）模式编写的时候。
不过程序员要小心的是，尽管可以通过setsockopt（）这个API来把SO_SNDBUF和SO_RCVBUF选项值设成0（关闭内部缓冲区），但是程序员必须十分清楚把AFD.SYS的内部缓冲区关掉会造成什么后果，避免收发数据时有关的缓冲区拷贝可能引起的系统崩溃。
举例来说，一个应用程序通过设定SO_SNDBUF为0把缓冲区关闭，然后发出一个阻塞send（）调用。
在这样的情况下，系统内核会把应用程序的缓冲区锁定，直到接收方确认收到了整个缓冲区后send（）调用才返回。
似乎这是一种判定你的数据是否已经为对方全部收到的简洁的方法，实际上却并非如此。
想想看，即使远端TCP通知数据已经收到，其实也根本不代表数据已经成功送给客户端应用程序，比如对方可能发生资源不足的情况，导致AFD.SYS不能把数据拷贝给应用程序。
另一个更要紧的问题是，在每个线程中每次只能进行一次发送调用，效率极其低下。
把SO_RCVBUF设为0，关闭AFD.SYS的接收缓冲区也不能让性能得到提升，这只会迫使接收到的数据在比Winsock更低的层次进行缓冲，当你发出receive调用时，同样要进行缓冲区拷贝，因此你本来想避免缓冲区拷贝的阴谋不会得逞。
现在我们应该清楚了，关闭缓冲区对于多数应用程序而言并不是什么好主意。
只要要应用程序注意随时在某个连接上保持几个WSARecvs重叠调用，那么通常没有必要关闭接收缓冲区。
如果AFD.SYS总是有由应用程序提供的缓冲区可用，那么它将没有必要使用内部缓冲区。
高性能的服务器应用程序可以关闭发送缓冲区，同时不会损失性能。
不过，这样的应用程序必须十分小心，保证它总是发出多个重叠发送调用，而不是等待某个重叠发送结束了才发出下一个。
如果应用程序是按一个发完再发下一个的顺序来操作，那浪费掉两次发送中间的空档时间，总之是要保证传输驱动程序在发送完一个缓冲区后，立刻可以转向另一个缓冲区。
资源的限制条件
在设计任何服务器应用程序时，其强健性是主要的目标。
也就是说，
你的应用程序要能够应对任何突发的问题，例如并发客户请求数达到峰值、可用内存临时出现不足、以及其它短时间的现象。
这就要求程序的设计者注意WindowsNT和2000系统下的资源限制条件的问题，从容地处理突发性事件。
你可以直接控制的、最基本的资源就是网络带宽。
通常，使用用户数据报协议（UDP）的应用程序都可能会比较注意带宽方面的限制，以最大限度地减少包的丢失。
然而，在使用TCP连接时，服务器必须十分小心地控制好，防止网络带宽过载超过一定的时间，否则将需要重发大量的包或造成大量连接中断。
关于带宽管理的方法应根据不同的应用程序而定，这超出了本文讨论的范围。
虚拟内存的使用也必须很小心地管理。
通过谨慎地申请和释放内存，或者应用lookasidelists（一种高速缓存）技术来重新使用已分配的内存，将有助于控制服务器应用程序的内存开销（原文为“让服务器应用程序留下的脚印小一点”），避免操作系统频繁地将应用程序申请的物理内存交换到虚拟内存中（原文为“让操作系统能够总是把更多的应用程序地址空间更多地保留在内存中”）。
你也可以通过SetWorkingSetSize（）这个Win32API让操作系统分配给你的应用程序更多的物理内存。
在使用Winsock时还可能碰到另外两个非直接的资源不足情况。
一个是被锁定的内存页面的极限。
如果你把AFD.SYS的缓冲关闭，当应用程序收发数据时，应用程序缓冲区的所有页面将被锁定到物理内存中。
这是因为内核驱动程序需要访问这些内存，在此期间这些页面不能交换出去。
如果操作系统需要给其它应用程序分配一些可分页的物理内存，而又没有足够的内存时就会发生问题。
我们的目标是要防止写出一个病态的、锁定所有物理内存、让系统崩溃的程序。
也就是说，你的程序锁定内存时，不要超出系统规定的内存分页极限。
在WindowsNT和2000系统上，所有应用程序总共可以锁定的内存大约是物理内存的1/8（不过这只是一个大概的估计，不是你计算内存的依据）。
如果你的应用程序不注意这一点，当你的发出太多的重叠收发调用，而且I/O没来得及完成时，就可能偶尔发生ERROR_INSUFFICIENT_RESOURCES的错误。
在这种情况下你要避免过度锁定内存。
同时要注意，系统会锁定包含你的缓冲区所在的整个内存页面，因此缓冲区靠近页边界时是有代价的（译者理解，缓冲区如果正好超过页面边界，那怕是1个字节，超出的这个字节所在的页面也会被锁定）。
另外一个限制是你的程序可能会遇到系统未分页池资源不足的情况。
所谓未分页池是一块永远不被交换出去的内存区域，这块内存用来存储一些供各种内核组件访问的数据，其中有的内核组件是不能访问那些被交换出去的页面空间的。
WindowsNT和2000的驱动程序能够从这个特定的未分页池分配内存。
当应用程序创建一个套接字（或者是类似的打开某个文件）时，内核会从未分页池中分配一定数量的内存，而且在绑定、连接套接字时，内核又会从未分页池中再分配一些内存。
当你注意观察这种行为时你将发现，如果你发出某些I/O请求时（例如收发数据），你会从未分页池里再分配多一些内存（比如要追踪某个待决的I/O操作，你可能需要给这个操作添加一个自定义结构，如前文所提及的）。
最后这就可能会造成一定的问题，操作系统会限制未分页内存的用量。
在WindowsNT和2000这两种操作系统上，给每个连接分配的未分页内存的具体数量是不同的，未来版本的Windows很可能也不同。
为了使应用程序的生命期更长，你就不应该计算对未分页池内存的具体需求量。
你的程序必须防止消耗到未分页池的极限。
当系统中未分页池剩余空间太小时，某些与你的应用程序毫无关系的内核驱动就会发疯，甚至造成系统崩溃，特别是当系统中有第三方设备或驱动程序时，更容易发生这样的惨剧（而且无法预测）。
同时你还要记住，同一台电脑上还可能运行有其它同样消耗未分页池的其它应用程序，因此在设计你的应用程序时，对资源量的预估要特别保守和谨慎。
处理资源不足的问题是十分复杂的，因为发生上述情况时你不会收到特别的错误代码，通常你只能收到一般性的WSAENOBUFS或者ERROR_INSUFFICIENT_RESOURCES错误。
要处理这些错误，首先，把你的应用程序工作配置调整到合理的最大值（译者注：
所谓工作配置，是指应用程序各部分运行中所需的内存用量，请参考，关于内存优化，译者另有译文），如果错误继续出现，那么注意检查是否是网络带宽不足的问题。
之后，请确认你没有同时发出太多的收发调用。
最后，如果还是收到资源不足的错误，那就很可能是遇到了未分页内存池不足的问题了。
要释放未分页内存池空间，请关闭应用程序中相当部分的连接，等待系统自行渡过和修正这个瞬时的错误。
接受连接请求
服务器要做的最普通的事情之一就是接受来自客户端的连接请求。
在套接字上使用重叠I/O接受连接的惟一API就是AcceptEx（）函数。
有趣的是，通常的同步接受函数accept（）的返回值是一个新的套接字，而AcceptEx（）函数则需要另外一个套接字作为它的参数之一。
这是因为AcceptEx（）是一个重叠操作，所以你需要事先创建一个套接字（但不要绑定或连接它），并把这个套接字通过参数传给AcceptEx（）。
以下是一小段典型的使用AcceptEx（）的伪代码：
do{
-等待上一个AcceptEx完成
-创建一个新套接字并与完成端口进行关联
-设置背景结构等等
-发出一个AcceptEx请求
}while（TRUE）;作为一个高响应能力的服务器，它必须发出足够的AcceptEx调用，守候着，一旦出现客户端连接请求就立刻响应。
至于发出多少个AcceptEx才够，就取决于你的服务器程序所期待的通信交通类型。
比如，如果进入连接率高的情况（因为连接
升级会员 