97久久精品人妻人人搡人人玩,精品久久久久中文字,国产99久久九九精品无码

Overlapped模型与CompletionPort模型

jay — Sat, 28 Apr 2007 09:14:00 GMT

摘自《Visual C++�|�络游戏建模与实现》（苏羽、王媛媛�~�著�Q?/strong>
Win32重叠I/O(Overloapped I/O)机制允许发�v一个操作，然后在操作完成之后接�?br>��C��息。对于那�U�需要很长时间才能完成的操作来说�Q�重叠I/O机制��其有用�Q�因为发�?br>重叠操作的线�E�在重叠��h��发出后就可以自由地做别的事情了�?br>    在Windows NT/2000上，提供真正可扩展的I/O模型��是使用完成端口�Q�Completion
Port)的重叠I/O�?br>    ……
    可以把完成端口看成系�l�维护的一个队列，操作�pȝ��把重叠I/O操作完成的事仉��知
攑ֈ�该队列里�Q�由于是暴露“操作完成”的事仉��知�Q�所以命名�ؓ(f��)“完成端口”�Q�Completion
Ports)。一个Socket被创建后�Q�可以在��M��时刻和一个完成端口联�p��v来�?br>    一般来��_(d��)��一个应用程序可以创建多个工作线�E�来处理完成端口上的通知事�g。工�?br>�U�程的数量依赖于�E�序的具体需要。但是在理想的情况下�Q�应该对应一个CPU创徏一个线
�E�。因为在完成端口理想模型中，每个�U�程都可以从�pȝ��获得一�?#8220;原子”性的旉��片，�?br>番运行�ƈ��(g��)查完成端口，�U�程的切换是额外的开销。在实际开发的时候，�q�要考虑�q�些�U?br>�E�是否牵涉到其他堵塞操作的情��c(di��n)��如果某�U�程�q�行堵塞操作�Q�系�l�则��其挂�v�Q�让别的
�U�程获得�q�行旉��。因此，如果有这��L(f��ng)��情况�Q�可以多创徏几个�U�程来尽量利用时间�?br>    应用完成端口分两步走�Q?br>    1. 创徏完成端口句柄�Q?br>    HANDLE hIocp;
    hIocp=CreateIoCompletionPort(
    INVALID_HANDLE_VALUE,
    NULL,
    (ULONG_PTR)0,
    0);
    if(hIocp==NULL) {
    //如果错误
      ……
    }
    注意在第1个参�?FileHandle)传入INVALID_FILE_HANDLE�Q�第2个参�?ExistingCompletionPort)
传入NULL�Q�系�l�将创徏一个新的完成端口句柄，没有��M��I/O句柄与其兌��?
    2. 完成端口创徏成功后，在Socket和完成端口之间徏立关联。再�ơ调用CreateIoCompletionPort
函数�Q�这一�ơ在�W?个参数FileHandle传入创徏的Socket句柄�Q�参数ExistingCompletionPort
为已�l�创建的完成端口句柄�?br>    以下代码创徏了一个Socket�q�把它和完成端口联系��h��?br>    SOCKET s;
    s=Socket(AF_INET,SOCK_STREAM,0);
    if(s==INVALID_SOCKET) {
    if(CreateIoCompletionPort((HANDLE)s,
    hIocp,
    (ULONG_PTR)0,
    0)==NULL)
    {
    //如果创徏��p�|
      ……
    }
    }
    到此为止�Q�Socket已经成功和完成端口相兌��。在此Socket�q�行的重叠I/O操作�l�果�?br>使用完成端口发出通知�?/p>
    注意�Q�CreateIoCompletionPort函数的第3个参数允许开发�h员传入一个类型�ؓ(f��)ULONG_PTR
的数据成员，我们把它�U�Cؓ(f��)完成�?Completion Key)�Q�此数据成员可以设计为指向包含Socket
信息的一个结构体的一个指针，用来把相关的环境信息和Socket联系��h��Q�每�ơ完成通知�?br>到的同时�Q�该环境信息也随着通知一赯��回给开发�h员�?/p>
    完成端口创徏以及(qi��ng)与Socket兌��之后�Q�就要创��Z��个或多个工作�U�程来处理完成通知�Q?br>每个�U�程都可以��@环地调用GetQueuedCompletionStatus函数�Q�检查完成端口上的通知事�g�?br>    在�D例说明一个典型的工作�U�程之前�Q�我们先讨论一下重叠I/O的过�E�。到一个重叠I/O
被发��P��一个Overlapped�l�构体的指针��p��作�ؓ(f��)参数传递给�pȝ��。当操作完成�Ӟ��
GetQueueCompletionStatus��可以返回指向同一个Overlapped�l�构的指针。�ؓ(f��)了��L认和定位
�q�个已完成的操作�Q�开发�h员最好定义自��q��OVERLAPPED�l�构�Q�以包含一些自己定义的关于
操作本��n的额外信息。比如：(x��)
    typedef struct _OVERLAPPELUS {
      OVERLAPPED ol;
      SOCKET s, sclient;
      int OpCode;
      WSABUF wbuf;
      DWORD dwBytes, dwFlags;
    } OVERLAPPELUS;
    此结构的�W?个成员�ؓ(f��)默认的OVERLAPPED�l�构�Q�第2和第3个�ؓ(f��)本地服务Socket和与�?br>操作相关的客户socket�Q�第4个成员�ؓ(f��)操作�c�d��Q�对于Socket�Q�现在定义的有以�?�U�：(x��)
    #define OP_READ 0
    #define OP_WRITE 1
    #define OP_ACCEPT 2
    然后�q�有应用�E�序的Socket�~�冲区，操作数据量，标志位以�?qi��ng)其他开发�h员认为有�?br>的信息�?br>    当进行重叠I/O操作�Q�把OVERLAPPELUS�l�构作�ؓ(f��)重叠I/O的参数l(f��)pOverlapp传递（�?br>WSASend�Q�W(xu��)ASRecv�Q�等函数的lpOverlapped参数�Q�要求传入一个OVERLAPP�l�构的指针）�?br>    当操作完成后�Q�GetQueuedCompletionStatus函数�q�回一个LPOVERLAPPED�c�d��的指针，
�q�个指针其实是指向开发�h员定义的扩展OVERLAPPELUS�l�构�Q�包含着开发�h员早先传入的
全部信息�?/p>
    注意�Q�OVERLAPPED成员不一定要求是OVERLAPPELUS扩展�l�构的一个成员，在获�?br>OVERLAPPED指针之后�Q�可以用CONTAINING_RECORD宏获得相应的扩展�l�构的指针�?/p>
    典型的Worker Thread�l�构�Q?br>    DWORD WINAPI WorkerThread(LPVOID lpParam)
    {
      ULONG_PTR *PerHandleKey;
      OVERLAPPED *Overlap;
      OVERLAPPELUS *OverlapPlus, *newolp;
      DWORD dwBytesXfered;

      while(1)
      {
        ret=GetQueuedCompletionStatus(
        hIocp,
        &dwBytesXfered,
        (PULONG_PTR)&PerHandleKey,
        &Overlap,
        INFINITE);
        if(ret==0)
        {
          //如果操作��p�|
          continue;
        }

        OverlapPlus=CONTATING_RECORD(Overlap, OVERLAPPELUS, ol);
        switch(OverlapPlus->OpCode)
        {
          case OP_ACCEPT:
            CreateIoCompletionPort(
                (HANDLE)OverlapPlus->sclient,
                hIocp,
                (ULONG_PTR)0,
                0);
            newolp=AllocateOverlappelus();
            newolp->s=OverlapPlus->sclient;
            newolp->OpCode=OP_READ;
            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)
              {
                //�q�行错误处理
                ……
              }
            }
            FreeOverlappelus(OverlapPlus);
            SetEvent(hAcceptThread);
            break;
          case OP_READ:
            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)
              {
                //错误处理
                ……
              }
            }
            break;
          case OP_WRITE:
            break;
        }/*switch�l�束*/
      }/*while�l�束*/
    }/*WorkerThread�l�束*/

    注意�Q�如果Overlapped操作立刻��p�|�Q�比如，�q�回SOCKET_ERROR或其他非
    WSA_IO_PENDING的错误）�Q�则没有��M��完成通知事�g�?x��)被攑ֈ�完成端口队列里。反之，
    则一定有相应的通知事�g被放到端口队列�?/p>

jay 2007-04-28 17:14 发表评论

点对点多�U�程断点�l�传的实现[转]

jay — Fri, 20 Apr 2007 07:18:00 GMT

在如今的�|�络应用中，文�g的传送是重要的功能之一�Q�也是共享的基础。一些重要的协议像HTTP�Q�FTP�{�都支持文�g的传送。尤其是FTP�Q�它的全�U�就�?#8220;文�g传送协�?#8221;�Q�当初的工程师设计这一协议��是��Z��解决�|�络间的文�g传送问题，而且以其�E�_��Q�高速，��单而一直保持着很大的生命力。作��Z��个程序员�Q��用这些现有的协议传送文件相当简单，不过�Q�它们只适用于服务器模式中。这��P��当我们想在点与点之间传送文件就不适用了或相当�ȝ��Q�有一�U�大刀��用的意呟뀂笔者一直想��L��一�U�简单有效，且具备多�U�程断点�l�传的方法来实现点与点之间的文�g传送问题，�l�过大量的翻阅资料与��试�Q�终于实��C��Q�现把它�׃�n出来�Q�与大家分��n�?br>我写了一个以此�ؓ(f��)基础的实用程序（�|�络传圣�Q�包含源代码�Q�，可用了基于TCP/IP的电(sh��)脑上�Q�供大家学习(f��n)�?br>

(本文源代码运行效果图)

实现�Ҏ(gu��)��Q�VC�Q�＋�Q�基于TCP/IP协议�Q�如下：(x��)
仍釆用服务器与客��h��式，需分别对其设计与编�E��?br>服务器端较简单，主要��是加入待传文�g�Q�监听客��P��和传送文件。而那些断点箋传的功能�Q�以�?qi��ng)文件的��理都放在客��L(f��ng)��上�?br>
一、服务器�?/strong>

首先介绍服务器端�Q?br>最开始我们要定义一个简单的协议�Q�也��是定义一个服务器端与客户端听得懂的语�a�。而�ؓ(f��)了把问题��化，我就让服务器只要听懂两句话，一��是客户�?#8220;我要��L��件信�?#8221;�Q�二��是“我准备好了，可以传文件了”�?br>�׃��要实现多�U�程�Q�必��L��功能独立出来�Q�且包装成线�E�，首先��Z��个监听线�E�，主要负责接入客户�Q��ƈ启动另一个客��L(f��ng)��E�。我用VC++实现如下�Q?br>

DWORD WINAPI listenthread(LPVOID lpparam) { //�׃��函数传来的套接字　　SOCKET pthis=(SOCKET)lpparam; //开始监�? int rc=listen(pthis,30); //如果错就昄��信息 if(rc<0){ CString aaa; aaa="listen错误\n"; AfxGetMainWnd()->SendMessageToDescendants(WM_AGE1,(LPARAM)aaa.GetBuffer(0),1); aaa.ReleaseBuffer(); return 0; } //�q�入循环�Q��ƈ接收到来的套接字 while(1){ //新徏一个套接字�Q�用于客��L(f��ng)�� SOCKET s1; s1=accept(pthis,NULL,NULL); 　 //�l�主函数发有��入消�? CString aa; aa="一��入！\n"; AfxGetMainWnd()->SendMessageToDescendants(WM_AGE1,(LPARAM)aa.GetBuffer(0),1); aa.ReleaseBuffer(); DWORD dwthread; //建立用户�U�程 ::CreateThread(NULL,0,clientthread,(LPVOID)s1,0,&dwthread); } return 0; }
接着我们来看用户�U�程�Q?br>先看文�g消息�c�d��?/strong>�Q?br>
struct fileinfo { int fileno;//文�g�? int type;//客户端想说什么（前面那两句话�Q�用1,2表示�Q? long len;//文�g长度 int seek;//文�g开始位�|�，用于多线�E? char name[100];//文�g�? };
用户�U�程函数:
DWORD WINAPI clientthread(LPVOID lpparam) { //文�g消息 fileinfo* fiinfo; //接收�~�存 char* m_buf; m_buf=new char[100]; //监听函数传来的用户套接字 SOCKET pthis=(SOCKET)lpparam; //��M��来的信息 int aa=readn(pthis,m_buf,100); //如果有错��p��? if(aa<0){ closesocket (pthis); return -1; } //把传来的信息转�ؓ(f��)定义的文件信�? fiinfo=(fileinfo*)m_buf; CString aaa; //��(g��)验客��h��说什�? switch(fiinfo->type) { //我要��L��件信�? case 0: //��L��? aa=sendn(pthis,(char*)zmfile,1080); //有错 if(aa<0){ closesocket (pthis); return -1; } //发消息给��d��? aaa="收到LIST命��o(h��)\n"; AfxGetMainWnd()->SendMessageToDescendants(WM_AGE1,(LPARAM)aaa.GetBuffer(0),1); break; //我准备好了，可以传文件了 case 2: //发文件消息给��d��? aaa.Format("%s 文�g被请求！%s\n",zmfile[fiinfo->fileno].name,nameph[fiinfo->fileno]); AfxGetMainWnd()->SendMessageToDescendants(WM_AGE1,(LPARAM)aaa.GetBuffer(0),1); //��L��Ӟ��q�传�? readfile(pthis,fiinfo->seek,fiinfo->len,fiinfo->fileno); //听不懂你说什�? default: aaa="接收协议错误�Q�\n"; AfxGetMainWnd()->SendMessageToDescendants(WM_AGE1,(LPARAM)aaa.GetBuffer(0),1); break; } return 0; }
��L��件函�?/strong>
void readfile(SOCKET so,int seek,int len,int fino) { //文�g�? CString myname; myname.Format("%s",nameph[fino]); CFile myFile; //打开文�g myFile.Open(myname, CFile::modeRead | CFile::typeBinary|CFile::shareDenyNone); //传到指定位置　 myFile.Seek(seek,CFile::begin); char m_buf[SIZE]; int len2; int len1; len1=len; //开始接�Ӟ��直到发完整个文�g while(len1>0){ len2=len>SIZE?SIZE:len; myFile.Read(m_buf, len2); int aa=sendn(so,m_buf,len2); if(aa<0){ closesocket (so); break; } len1=len1-aa; len=len-aa; } myFile.Close(); }

服务器端最要的功能各技术就是这些，下面介绍客户端�?br>
二、客��L(f��ng)��

客户端最重要�Q�也最复杂�Q�它负责�U�程的管理，�q�度的记录等工作�?br>
大概��程如下�Q?br>先连接服务器�Q�接着发送命�?�Q�给我文件信息）�Q�其中包括文仉��度，名字�{�，然后�Ҏ(gu��)��长度军_��分几个线�E�下载，�q�初使化下蝲�q�程�Q�接着发送命�?�Q�可以给我传文�g了）�Q��ƈ记录文�g�q�程。最后，收尾�?br>�q�其中有一个十分重要的�c�，��是cdownload�c�，定义如下�Q?

class cdownload { public: void createthread();//开�U�程 DWORD finish1();//完成�U�程 int sendlist();//发命�? downinfo doinfo;//文�g信息�Q�与服务器定义一��P�� int startask(int n);开始传文�gn long m_index; BOOL good[BLACK]; int filerange[100]; CString fname; CString fnametwo; UINT threadfunc(long index);//下蝲�q�程 int sendrequest(int n);//发文件信�? cdownload(int thno1); virtual ~cdownload(); };
下面先介�l�sendrequest(int n)�Q�在开始前�Q�向服务器发获得文�g消息命��o(h��)�Q�以便让客户端知道有哪些文�g可传
int cdownload::sendrequest(int n) { //建套接字 sockaddr_in local; SOCKET m_socket; int rc=0; //初��化服务器地址 local.sin_family=AF_INET; local.sin_port=htons(1028); local.sin_addr.S_un.S_addr=inet_addr(ip); m_socket=socket(AF_INET,SOCK_STREAM,0); int ret; //联接服务�? ret=connect(m_socket,(LPSOCKADDR)&local,sizeof(local)); //有错的话 if(ret<0){ AfxMessageBox("联接错误"); closesocket(m_socket); return -1; } //初��化命�? fileinfo fileinfo1; fileinfo1.len=n; fileinfo1.seek=50; fileinfo1.type=1; //发送命�? int aa=sendn(m_socket,(char*)&fileinfo1,100); if(aa<0){ closesocket(m_socket); return -1; } //接收服务器传来的信息 aa=readn(m_socket,(char*)&fileinfo1,100); if(aa<0){ closesocket(m_socket); return -1; } //关闭 shutdown(m_socket,2); closesocket(m_socket); return 1; }
有了文�g消息后我们就可以下蝲文�g了。在��d��C��Q�用法如下：(x��)
//下蝲�W�clno个文�Ӟ��q��ؓ(f��)它徏一个新cdownload�c? down[clno]=new cdownload(clno); //开始下载，�q�初使化 type=down[clno]->startask(clno); //建立各线�E? createthread(clno);
下面介绍开始方�?/strong>:
//开始方�? int cdownload::startask(int n) { //��d��文�g长度 doinfo.filelen=zmfile[n].length; //��d��名字 fname=zmfile[n].name; CString tmep; //初��化文件名 tmep.Format("\\temp\\%s",fname); //�l�主函数发消�? CString aaa; aaa="正在��d�� "+fname+" 信息�Q�马上开始下载。。。\n"; AfxGetMainWnd()->SendMessageToDescendants(WM_AGE1,(LPARAM)aaa.GetBuffer(0),1); aaa.ReleaseBuffer(); //如果文�g长度��于0��p��? if(doinfo.filelen<=0) return -1; //��Z��个以.down�l�尾的文件记录文件信�? CString m_temp; m_temp=fname+".down"; doinfo.name=m_temp; FILE* fp=NULL; CFile myfile; //如果是第一�ơ下载文�Ӟ��初��化各记录文�g if((fp=fopen(m_temp,"r"))==NULL){ filerange[0]=0; //文�g分块 for(int i=0;i0) filerange[i*2]=i*(doinfo.filelen/BLACK+1); filerange[i*2+1]=doinfo.filelen/BLACK+1; } filerange[BLACK*2-1]=doinfo.filelen-filerange[BLACK*2-2]; myfile.Open(m_temp,CFile::modeCreate|CFile::modeWrite | CFile::typeBinary); //写入文�g长度 myfile.Write(&doinfo.filelen,sizeof(int)); myfile.Close(); 　 CString temp; for(int ii=0;iim_work.m_ListCtrl->AddItemtwo(n,2,0,0,0,doinfo.threadno); } else{ //如果文�g已存在，说明是箋传，��M��ơ信�? CString temp; 　 m_temp=fname+".down0"; if((fp=fopen(m_temp,"r"))==NULL) return 1; else fclose(fp); int bb; bb=0; //��d��q�程记录的信�? for(int ii=0;iim_work.m_ListCtrl->AddItemtwo(n,2,doinfo.totle,1,0,doinfo.threadno); } 　 //建立下蝲�l�束�q�程timethread�Q�以��现各进�E�结束时间�? DWORD dwthread; ::CreateThread(NULL,0,timethread,(LPVOID)this,0,&dwthread); return 0; }
下面介绍建立各进�E?/strong>函数�Q�很��单：(x��)
void CMainFrame::createthread(int threadno) { DWORD dwthread; //建立BLACK个进�E? for(int i=0;i downthread�q�程函数
DWORD WINAPI downthread(LPVOID lpparam) { cdownload* pthis=(cdownload*)lpparam; //�q�程引烦�Q? InterlockedIncrement(&pthis->m_index); //执行下蝲�q�程 pthis->threadfunc(pthis->m_index-1); return 1; }
下面介绍下蝲�q�程函数,最最核心的东西了
UINT cdownload::threadfunc(long index) { //初��化联�? sockaddr_in local; SOCKET m_socket; int rc=0; 　 local.sin_family=AF_INET; local.sin_port=htons(1028); local.sin_addr.S_un.S_addr=inet_addr(ip); m_socket=socket(AF_INET,SOCK_STREAM,0); int ret; //��d��~�存 char* m_buf=new char[SIZE]; int re,len2; fileinfo fileinfo1; //联接 ret=connect(m_socket,(LPSOCKADDR)&local,sizeof(local)); //��d��各进�E�的下蝲信息 fileinfo1.len=filerange[index*2+1]; fileinfo1.seek=filerange[index*2]; fileinfo1.type=2; fileinfo1.fileno=doinfo.threadno; 　 re=fileinfo1.len; 　 //打开文�g　 CFile destFile; FILE* fp=NULL; //是第一�ơ传的话 if((fp=fopen(fname,"r"))==NULL) destFile.Open(fname, CFile::modeCreate|CFile::modeWrite | CFile::typeBinary|CFile::shareDenyNone); else //如果文�g存在�Q�是�l�传 destFile.Open(fname,CFile::modeWrite | CFile::typeBinary|CFile::shareDenyNone); //文�g指针�U�d��指定位置 destFile.Seek(filerange[index*2],CFile::begin); //发消息给服务器，可以传文件了 sendn(m_socket,(char*)&fileinfo1,100); CFile myfile; CString temp; temp.Format(".down%d",index); m_temp=fname+temp; 　 //当各�D�长度还不�ؓ(f��)0�? while(re>0){ len2=re>SIZE?SIZE:re; 　 //��d��D�内�? int len1=readn(m_socket,m_buf,len2); //有错的话 if(len1<0){ closesocket(m_socket); break; } 　 //写入文�g destFile.Write(m_buf, len1); //更改记录�q�度信息 filerange[index*2+1]-=len1; filerange[index*2]+=len1; //�U�d��记录文�g指针到头 myfile.Seek(0,CFile::begin); //写入记录�q�度 myfile.Write(&filerange[index*2],sizeof(int)); myfile.Write(&filerange[index*2+1],sizeof(int)); //减去�q�次�ȝ��长度 re=re-len1; //加文仉��? doinfo.totle=doinfo.totle+len1; }; //�q�块下蝲完成�Q�收��? 　 myfile.Close(); destFile.Close(); delete [] m_buf; shutdown(m_socket,2); 　　 if(re<=0) good[index]=TRUE; return 1; }

到这客户端的主要模块和机制已基本介绍完。希望好好体�?x��)一下这�U�多�U�程断点�l�传的方法�?

jay 2007-04-20 15:18 发表评论

用完成端口开发大响应规模的Winsock应用�E�序[转]

jay — Thu, 19 Apr 2007 06:05:00 GMT

原文出处�Q?a target=_blank>http://msdn.microsoft.com/msdnmag/issues/1000/Winsock/

通常要开发网�l�应用程序�ƈ不是一件轻杄��事情�Q�不�q�，实际上只要掌握几个关键的原则也就可以了——创建和�q�接一个套接字�Q�尝试进行连接，然后收发数据。真正难的是要写��Z��个可以接�U�_��则一个，多则数千个连接的�|�络应用�E�序。本文将讨论如何通过Winsock2在Windows NT �?Windows 2000上开发高扩展能力的Winsock应用�E�序。文章主要的焦点在客��h��/服务器模型的服务器这一方，当然�Q�其中的许多要点�Ҏ(gu��)��型的双方都适用�?

API与响应规�?/strong>

通过Win32的重叠I/O机制�Q�应用程序可以提请一��I/O操作�Q�重叠的操作��h��在后台完成，而同一旉��提请操作的线�E�去做其他的事情。等重叠操作完成后线�E�收到有关的通知。这�U�机制对那些耗时的操作而言特别有用。不�q�，像Windows 3.1上的WSAAsyncSelect()�?qi��ng)Unix下的select()那样的函数虽然易于��用，但是它们不能满��响应规模的需要。而完成端口机制是针对操作�pȝ��内部�q�行了优化，在Windows NT �?Windows 2000上，使用了完成端口的重叠I/O机制才能够真正扩大系�l�的响应规模�?/p>
完成端口

一个完成端口其实就是一个通知队列�Q�由操作�pȝ��把已�l�完成的重叠I/O��h��的通知攑օ�其中。当某项I/O操作一旦完成，某个可以对该操作�l�果�q�行处理的工作者线�E�就�?x��)收��C��则通知。而套接字在被创徏后，可以在�Q何时候与某个完成端口�q�行兌��?/p>
通常情况下，我们�?x��)在应用�E�序中创��Z��定数量的工作者线�E�来处理�q�些通知。线�E�数量取决于应用�E�序的特定需要。理想的情况是，�U�程数量�{�于处理器的数量�Q�不�q�这也要求�Q何线�E�都不应该执行诸如同步读写、等待事仉��知�{�阻塞型的操作，以免�U�程��d��。每个线�E�都��分��C��定的CPU旉��Q�在此期间该�U�程可以�q�行�Q�然后另一个线�E�将分到一个时间片�q�开始执行。如果某个线�E�执行了��d��型的操作�Q�操作系�l�将剥夺其未使用的剩余时间片�q�让其它�U�程开始执行。也��是��_(d��)��前一个线�E�没有充分��用其旉��片，当发生这��L(f��ng)��情况�Ӟ��应用�E�序应该准备其它�U�程来充分利用这些时间片�?/p>
完成端口的��用分��Z��步。首先创建完成端口，如以下代码所�C�：(x��)

HANDLE hIocp; hIocp = CreateIoCompletionPort( INVALID_HANDLE_VALUE, NULL, (ULONG_PTR)0, 0); if (hIocp == NULL) { // Error }
完成端口创徏后，要把��用该完成端口的套接字与之兌��h��。方法是再次调用CreateIoCompletionPort ()函数�Q�第一个参数FileHandle设�ؓ(f��)套接字的句柄�Q�第二个参数ExistingCompletionPort 设�ؓ(f��)刚刚创徏的那个完成端口的句柄�?br>以下代码创徏了一个套接字�Q��ƈ把它和前面创建的完成端口兌��h��Q?
SOCKET s; s = socket(AF_INET, SOCK_STREAM, 0); if (s == INVALID_SOCKET) { // Error if (CreateIoCompletionPort((HANDLE)s, hIocp, (ULONG_PTR)0, 0) == NULL) { // Error } ... }

�q�时��完成了套接字与完成端口的关联操作。在�q�个套接字上�q�行的�Q何重叠操作都��通过完成端口发出完成通知。注意，CreateIoCompletionPort()函数中的�W�三个参数用来设�|�一个与该套接字相关�?#8220;完成�?completion key)”(译者注�Q�完成键可以是�Q何数据类�?。每当完成通知到来�Ӟ��应用�E�序可以��d��相应的完成键�Q�因此，完成键可用来�l�套接字传递一些背景信息�?
在创��Z��完成端口、将一个或多个套接字与之相兌��之后�Q�我们就要创��q�个�U�程来处理完成通知。这些线�E�不断��@环调用GetQueuedCompletionStatus ()函数�q�返回完成通知�?/p>
下面�Q�我们先来看看应用程序如何跟�t�这些重叠操作。当应用�E�序调用一个重叠操作函数时�Q�要把指向一个overlapped�l�构的指针包括在其参��C��。当操作完成后，我们可以通过GetQueuedCompletionStatus()函数中拿回这个指针。不�q�，单是�Ҏ(gu��)��q�个指针所指向的overlapped�l�构�Q�应用程序�ƈ不能分��L�I�竟完成的是哪个操作。要实现�Ҏ(gu��)��作的跟踪�Q�你可以自己定义一个OVERLAPPED�l�构�Q�在其中加入所需的跟�t�信息�?/p>
无论何时调用重叠操作函数�Ӟ��L��?x��)通过其lpOverlapped参数传递一个OVERLAPPEDPLUS�l�构(例如WSASend�?WSARecv�{�函�?。这��允�怽�为每一个重叠调用操作设�|�某些操作状态信息，当操作结束后�Q�你可以通过GetQueuedCompletionStatus()函数获得你自定义�l�构的指针。注意OVERLAPPED字段不要求一定是�q�个扩展后的�l�构的第一个字�D�c(di��n)��当得到了指向OVERLAPPED�l�构的指针以后，可以用CONTAINING_RECORD宏取出其中指向扩展结构的指针�?/p>
OVERLAPPED �l�构的定义如下：(x��)

typedef struct _OVERLAPPEDPLUS { OVERLAPPED ol; SOCKET s, sclient; int OpCode; WSABUF wbuf; DWORD dwBytes, dwFlags; // 其它有用的信�? } OVERLAPPEDPLUS; #define OP_READ 0 #define OP_WRITE 1 #define OP_ACCEPT 2
下面让我们来看看工作者线�E�的情况�?br>
工作�U�程WorkerThread代码�Q?
DWORD WINAPI WorkerThread(LPVOID lpParam) { ULONG_PTR *PerHandleKey; OVERLAPPED *Overlap; OVERLAPPEDPLUS *OverlapPlus, *newolp; DWORD dwBytesXfered; while (1) { ret = GetQueuedCompletionStatus( hIocp, &dwBytesXfered, (PULONG_PTR)&PerHandleKey, &Overlap, INFINITE); if (ret == 0) { // Operation failed continue; } OverlapPlus = CONTAINING_RECORD(Overlap, OVERLAPPEDPLUS, ol); switch (OverlapPlus->OpCode) { case OP_ACCEPT: // Client socket is contained in OverlapPlus.sclient // Add client to completion port CreateIoCompletionPort( (HANDLE)OverlapPlus->sclient, hIocp, (ULONG_PTR)0, 0); // Need a new OVERLAPPEDPLUS structure // for the newly accepted socket. Perhaps // keep a look aside list of free structures. newolp = AllocateOverlappedPlus(); if (!newolp) { // Error } newolp->s = OverlapPlus->sclient; newolp->OpCode = OP_READ; // This function prepares the data to be sent 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 } } // Put structure in look aside list for later use FreeOverlappedPlus(OverlapPlus); // Signal accept thread to issue another AcceptEx SetEvent(hAcceptThread); break; case OP_READ: // Process the data read // ... // Repost the read if necessary, reusing the same // receive buffer as before 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; case OP_WRITE: // Process the data sent, etc. break; } // switch } // while } // WorkerThread
其中每句柄键(PerHandleKey)变量的内容，是在把完成端口与套接字进行关联时所讄��的完成键参数�Q�Overlap参数�q�回的是一个指向发出重叠操作时所使用的那个OVERLAPPEDPLUS�l�构的指针�?
要记住，如果重叠操作调用��p�|�?也就是说�Q�返回值是SOCKET_ERROR�Q��ƈ且错误原因不是WSA_IO_PENDING)�Q�那么完成端口将不会(x��)收到��M��完成通知。如果重叠操作调用成功，或者发生原因是WSA_IO_PENDING的错误时�Q�完成端口将��L��能够收到完成通知�?br>
Windows NT和W(xu��)indows 2000的套接字架构

对于开发大响应规模的Winsock应用�E�序而言�Q�对Windows NT和W(xu��)indows 2000的套接字架构有基本的了解是很有帮助的。下图是Windows 2000中的Winsock架构�Q?br>

与其它类型操作系�l�不同，W(xu��)indows NT和W(xu��)indows 2000的传输协议没有一�U�风格像套接字那��L(f��ng)��、可以和应用�E�序直接交谈的界面，而是采用了一�U�更为底层的API�Q�叫做传输驱动程序界�?Transport Driver Interface,TDI)。Winsock的核心模式驱动程序负责连接和�~�冲区管理，以便向应用程序提供套接字仿真(在AFD.SYS文�g中实�?�Q�同时负责与底层传输驱动�E�序对话�?/p>
谁来负责��理�~�冲区？

正如上面所说的�Q�应用程序通过Winsock来和传输协议驱动�E�序交谈�Q�而AFD.SYS负责为应用程序进行缓冲区��理。也��是��_(d��)��当应用程序调用send()或WSASend()函数来发送数据时�Q�AFD.SYS��把数据拯��q�它自己的内部缓冲区(取决于SO_SNDBUF讑֮��?�Q�然后send()或WSASend()函数立即�q�回。也可以�q�么��_(d��)��AFD.SYS在后台负责把数据发送出厅R��不�q�，如果应用�E�序要求发出的数据超�q�了SO_SNDBUF讑֮�的缓冲区大小�Q�那么WSASend()函数�?x��)阻塞，直至所有数据发送完毕�?/p>
从远�E�客��L(f��ng)��接收数据的情况也�c�M��。只要不用从应用�E�序那里接收大量的数据，而且没有��出SO_RCVBUF讑֮�的��|��AFD.SYS��把数据先拷贝到其内部缓冲区中。当应用�E�序调用recv()或WSARecv()函数�Ӟ��数据��从内部�~�冲拯��到应用程序提供的�~�冲区�?/p>
多数情况下，�q�样的架构运行良好，特别在是应用�E�序采用传统的套接字下非重叠的send()和receive()模式�~�写的时候。不�q�程序员要小心的是，��管可以通过setsockopt()�q�个API来把SO_SNDBUF和SO_RCVBUF选项��D��?(关闭内部�~�冲�?�Q�但是程序员必须十分清楚把AFD.SYS的内部缓冲区��x��?x��)造成什么后果，避免收发数据时有关的�~�冲区拷贝可能引��L(f��ng)��pȝ��崩溃�?/p>
举例来说�Q�一个应用程序通过讑֮�SO_SNDBUF�?把缓冲区关闭�Q�然后发��Z��个阻塞send()调用。在�q�样的情况下�Q�系�l�内�怼�(x��)把应用程序的�~�冲区锁定，直到接收方确认收��C��整个�~�冲区后send()调用才返回。似乎这是一�U�判定你的数据是否已�l��ؓ(f��)�Ҏ(gu��)��全部收到的简�z�的�Ҏ(gu��)��Q�实际上却�ƈ非如此。想想看�Q�即使远端TCP通知数据已经收到�Q�其实也�Ҏ(gu��)��不代表数据已�l�成功送给客户端应用程序，比如�Ҏ(gu��)��可能发生资源不��的情况，��D��AFD.SYS不能把数据拷贝给应用�E�序。另一个更要紧的问题是�Q�在每个�U�程中每�ơ只能进行一�ơ发送调用，效率极其低下�?/p>
把SO_RCVBUF设�ؓ(f��)0�Q�关闭AFD.SYS的接收缓冲区也不能让性能得到提升�Q�这只会(x��)�q��接收到的数据在比Winsock更低的层�ơ进行缓�Ԍ��当你发出receive调用�Ӟ��同样要进行缓冲区拯��Q�因此你本来想避免缓冲区拯��的阴谋不�?x��)得逞�?/p>
现在我们应该清楚了，关闭�~�冲区对于多数应用程序而言�q�不是什么好��L��。只要要应用�E�序注意随时在某个连接上保持几个WSARecvs重叠调用�Q�那么通常没有必要关闭接收�~�冲区。如果AFD.SYS��L��有由应用�E�序提供的缓冲区可用�Q�那么它?y��u)��没有必要��用内部缓冲区�?/p>
高性能的服务器应用�E�序可以关闭发送缓冲区�Q�同时不�?x��)损失性能。不�q�，�q�样的应用程序必��d��分小心，保证它��L��发出多个重叠发送调用，而不是等待某个重叠发送结束了才发��Z��一个。如果应用程序是按一个发完再发下一个的��序来操作，那浪�Ҏ(gu��)��两次发送中间的�I�档旉��Q��M��是要保证传输驱动�E�序在发送完一个缓冲区后，立刻可以转向另一个缓冲区�?/p>
资源的限制条�?/strong>

在设计�Q何服务器应用�E�序�Ӟ��其强健性是主要的目标。也��是��_(d��)��

你的应用�E�序要能够应对�Q何突发的问题�Q�例如�ƈ发客戯��求数辑ֈ�峰倹{��可用内存��(f��)时出��C��뀁以�?qi��ng)其它短旉��的现象。这��p��求程序的设计者注意Windows NT�?000�pȝ��下的资源限制条�g的问题，从容地处理突发性事件�?/p>
你可以直接控制的、最基本的资源就是网�l�带宽。通常�Q��用用��h��据报协议(UDP)的应用程序都可能�?x��)比较注意带宽方面的限制�Q�以最大限度地减少包的丢失。然而，在��用TCP�q�接�Ӟ��服务器必��d��分小心地控制好，防止�|�络带宽�q�蝲��过一定的旉��Q�否则将需要重发大量的包或造成大量�q�接中断。关于带宽管理的�Ҏ(gu��)��应根据不同的应用�E�序而定�Q�这��出了本文讨论的范围�?/p>
虚拟内存的��用也必须很小心地��理。通过谨慎地申请和释放内存�Q�或者应用lookaside lists(一�U�高速缓�?技术来重新使用已分配的内存�Q�将有助于控制服务器应用�E�序的内存开销(原文�?#8220;让服务器应用�E�序留下的脚印小一�?#8221;)�Q�避免操作系�l�频�J�地��应用程序申��L(f��ng)��物理内存交换到虚拟内存中(原文�?#8220;让操作系�l�能够��L��把更多的应用�E�序地址�I�间更多��C��留在内存�?#8221;)。你也可以通过SetWorkingSetSize()�q�个Win32 API让操作系�l�分配给你的应用�E�序更多的物理内存�?/p>
在��用Winsock时还可能��到另外两个非直接的资源不��情况。一个是被锁定的内存��面的极限。如果你把AFD.SYS的缓冲关闭，当应用程序收发数据时�Q�应用程序缓冲区的所有页面将被锁定到物理内存中。这是因为内栔R��动程序需要访问这些内存，在此期间�q�些��面不能交换出去。如果操作系�l�需要给其它应用�E�序分配一些可分页的物理内存，而又没有��_��的内存时��׃��(x��)发生问题。我们的目标是要防止写出一个病态的、锁定所有物理内存、让�pȝ��崩溃的程序。也��是��_(d��)��你的�E�序锁定内存�Ӟ��不要��出�pȝ��规定的内存分��|��限�?/p>
在Windows NT�?000�pȝ��上，所有应用程序��d��可以锁定的内存大�U�是物理内存�?/8(不过�q�只是一个大概的估计�Q�不是你计算内存的依�?。如果你的应用程序不注意�q�一点，当你的发出太多的重叠收发调用�Q�而且I/O没来得及(qi��ng)完成�Ӟ��可能偶��?d��ng)发生ERROR_INSUFFICIENT_RESOURCES的错误。在�q�种情况下你要避免过度锁定内存。同时要注意�Q�系�l�会(x��)锁定包含你的�~�冲区所在的整个内存��面�Q�因此缓冲区靠近��边界时是有代�h(hu��n)�?译者理解，�~�冲区如果正好超�q�页面边界，那怕是1个字节，��出的这个字节所在的��面也会(x��)被锁�?�?/p>
另外一个限制是你的�E�序可能�?x��)遇到系�l�未分页池资源不��的情况。所谓未分页池是一块永�q�不被交换出�ȝ��内存区域�Q�这块内存用来存储一些供各种内核�l��g讉K��的数据，其中有的内核�l��g是不能访问那些被交换出去的页面空间的。Windows NT�?000的驱动程序能够从�q�个特定的未分页池分配内存�?/p>
当应用程序创��Z��个套接字(或者是�c�M��的打开某个文�g)�Ӟ��内核�?x��)从未分��|��中分配一定数量的内存�Q�而且在绑定、连接套接字�Ӟ��内核又会(x��)从未分页池中再分配一些内存。当你注意观察这�U�行为时你将发现�Q�如果你发出某些I/O��h��?例如收发数据)�Q�你�?x��)从未分��|��里再分配多一些内�?比如要追�t�某个待决的I/O操作�Q�你可能需要给�q�个操作��d��一个自定义�l�构�Q�如前文所提及(qi��ng)�?。最后这��可能会(x��)造成一定的问题�Q�操作系�l�会(x��)限制未分��内存的用量�?/p>
在Windows NT�?000�q�两�U�操作系�l�上�Q�给每个�q�接分配的未分页内存的具体数量是不同的，未来版本的Windows很可能也不同。�ؓ(f��)了��应用�E�序的生命期更长�Q�你��׃��应该计算�Ҏ(gu��)��分页池内存的具体需求量�?/p>
你的�E�序必须防止消耗到未分��|��的极限。当�pȝ��中未分页池剩余空间太��时�Q�某些与你的应用�E�序毫无关系的内栔R��动就�?x��)发疯，甚至造成�pȝ��崩溃�Q�特别是当系�l�中有第三方讑֤�或驱动程序时�Q�更�Ҏ(gu��)��发生�q�样的惨�?而且无法预测)。同时你�q�要��C��Q�同一台电(sh��)脑上�q�可能运行有其它同样消耗未分页池的其它应用�E�序�Q�因此在设计你的应用�E�序�Ӟ��对资源量的预估要特别保守和�}慎�?/p>
处理资源不��的问题是十分复杂的，因�ؓ(f��)发生上述情况时你不会(x��)收到特别的错误代码，通常你只能收��C��般性的WSAENOBUFS或者ERROR_INSUFFICIENT_RESOURCES 错误。要处理�q�些错误�Q�首先，把你的应用程序工作配�|�调整到合理的最大�?译者注�Q�所谓工作配�|�，是指应用�E�序各部分运行中所需的内存用量，请参�?http://msdn.microsoft.com/msdnmag/issues/1000/Bugslayer/Bugslayer1000.asp �Q�关于内存优化，译者另有译�?�Q�如果错误��l�出玎ͼ�那么注意��(g��)查是否是�|�络带宽不��的问题。之后，��L(f��ng)��认你没有同时发出太多的收发调用。最后，如果�q�是收到资源不��的错误，那就很可能是遇到了未分页内存池不��的问题了。要释放未分��内存池�I�间�Q�请关闭应用�E�序中相当部分的�q�接�Q�等待系�l�自行渡�q�和修正�q�个瞬时的错误�?br>
接受�q�接��h��

服务器要做的最普通的事情之一��是接受来自客户端的�q�接��h��。在套接字上使用重叠I/O接受�q�接的惟一API��是AcceptEx()函数。有��的是，通常的同步接受函数accept()的返回值是一个新的套接字�Q�而AcceptEx()函数则需要另外一个套接字作�ؓ(f��)它的参数之一。这是因为AcceptEx()是一个重叠操作，所以你需要事先创��Z��个套接字(但不要绑定或�q�接�?�Q��ƈ把这个套接字通过参数传给AcceptEx()。以下是一��段典型的��用AcceptEx()的伪代码�Q?

do { -�{�待上一�?AcceptEx 完成 -创徏一个新套接字�ƈ与完成端口进行关�? -讄��背景�l�构�{�等 -发出一�?AcceptEx ��h�� }while(TRUE);
作�ؓ(f��)一个高响应能力的服务器�Q�它必须发出��_��的AcceptEx调用�Q�守候着�Q�一旦出现客��L(f��ng)��q�接��h��q��d��应。至于发出多��个AcceptEx才够�Q�就取决于你的服务器�E�序所期待的通信交通类型。比如，如果�q�入�q�接率高的情�?因�ؓ(f��)�q�接持箋旉��较短�Q�或者出��C��通高�?�Q�那么所需要守候的AcceptEx当然要比那些偶尔�q�入的客��L(f��ng)��q�接的情况要多。聪明的做法是，由应用程序来分析交通状况，�q�调整AcceptEx守候的数量�Q�而不是固定在某个数量上�?
对于Windows2000�Q�W(xu��)insock提供了一些机�Ӟ��帮助你判定AcceptEx的数量是否��够。这��是�Q�在创徏监听套接字时创徏一个事�Ӟ��通过WSAEventSelect()�q�个API�q�注册FD_ACCEPT事�g通知来把套接字和�q�个事�g兌��h��。一旦系�l�收��C��个连接请求，如果�pȝ��中没有AcceptEx()正在�{�待接受�q�接�Q�那么上面的事�g��收��C��个信受��通过�q�个事�g�Q�你��可以判断你有没有发��够的AcceptEx()�Q�或者检��出一个非正常的客戯��?下文�q?。这�U�机制对Windows NT 4.0不适用�?/p>
使用AcceptEx()的一大好处是�Q�你可以通过一�ơ调用就完成接受客户端连接请求和接受数据(通过传送lpOutputBuffer参数)两�g事情。也��是��_(d��)��如果客户端在发出�q�接的同时传输数据，你的AcceptEx()调用在连接创建�ƈ接收了客��L(f��ng)��数据后就可以立刻�q�回。这样可能是很有用的�Q�但是也可能�?x��)引发问题，因��?f��)AcceptEx()必须�{�全部客��L(f��ng)��数据都收��C��才返回。具体来��_(d��)��如果你在发出AcceptEx()调用的同时传递了lpOutputBuffer参数�Q�那么AcceptEx()不再是一��原子型的操作，而是分成了两步：(x��)接受客户�q�接�Q�等待接收数据。当�~�少一�U�机制来通知你的应用�E�序所发生的这�U�情况：(x��)“�q�接已经建立了，正在�{�待客户端数�?#8221;�Q�这��意味着有可能出现客��L(f��ng)��只发��接请求，但是不发送数据。如果你的服务器收到太多�q�种�c�d��的连接时�Q�它?y��u)��拒�l�连接更多的合法客户端请求。这��是黑客�q�行“拒绝服务”��d��的常见手法�?/p>
要预防此�c�L��击，接受�q�接的线�E�应该不时地通过调用getsockopt()函数(选项参数为SO_CONNECT_TIME)来检查AcceptEx()里守候的套接字。getsockopt()函数的选项值将被设�|��ؓ(f��)套接字被�q�接的时��_(d��)��或者设�|��ؓ(f��)-1(代表套接字尚未徏立连�?。这�Ӟ��W(xu��)SAEventSelect()的特性就可以很好地利用来做这�U�检查。如果发现连接已�l�徏立，但是很久都没有收到数据的情况�Q�那么就应该�l�止�q�接�Q�方法就是关闭作为参数提供给AcceptEx()的那个套接字。注意，在多数非紧急情况下�Q�如果套接字已经传递给AcceptEx()�q�开始守候，但还未徏立连接，那么你的应用�E�序不应该关闭它们。这是因为即使关闭了�q�些套接字，��Z��提高�pȝ��性能的考虑�Q�在�q�接�q�入之前�Q�或者监听套接字自��n被关闭之前，相应的内核模式的数据�l�构也不�?x��)被�q�净地清除�?/p>
发出AcceptEx()调用的线�E�，��g��与那个进行完成端口关联操作、处理其它I/O完成通知的线�E�是同一个，但是�Q�别忘记�U�程里应该尽力避免执行阻塞型的操作。Winsock2分层�l�构的一个副作用是调用socket()或WSASocket() API的上层架构可能很重要(译者不太明白原文意思，抱歉)。每个AcceptEx()调用都需要创��Z��个新套接字，所以最好有一个独立的�U�程专门调用AcceptEx()�Q�而不参与其它I/O处理。你也可以利用这个线�E�来执行其它��d��Q�比如事件记录�?/p>
有关AcceptEx()的最后一个注意事��：(x��)要实现这些API�Q��ƈ不需要其它提供商提供的Winsock2实现。这一点对微��Y�Ҏ(gu��)��的其它API也同样适用�Q�比如TransmitFile()和GetAcceptExSockAddrs()�Q�以�?qi��ng)其它可能�?x��)被加入到新版Windows的API. 在Windows NT�?000上，�q�些API是在微��Y的底层提供者DLL(mswsock.dll)中实现的�Q�可通过与mswsock.lib�~�译�q�接�q�行调用�Q�或者通过WSAIoctl() (选项参数为SIO_GET_EXTENSION_FUNCTION_POINTER)动态获得函数的指针�?/p>
如果在没有事先获得函数指针的情况下直接调用函�?也就是说�Q�编译时静态连接mswsock.lib�Q�在�E�序中直接调用函�?�Q�那么性能��很受媄响。因为AcceptEx()被置于Winsock2架构之外�Q�每�ơ调用时它都被迫通过WSAIoctl()取得函数指针。要避免�q�种性能损失�Q�需要��用这些API的应用程序应该通过调用WSAIoctl()直接从底层的提供者那里取得函数的指针�?br>
参见下图套接字架构：(x��)

TransmitFile �?TransmitPackets

Winsock 提供两个专门为文件和内存数据传输�q�行了优化的函数。其中TransmitFile()�q�个API函数在Windows NT 4.0 �?Windows 2000上都可以使用�Q�而TransmitPackets()则将在未来版本的Windows中实现�?/p>
TransmitFile()用来把文件内定w��过Winsock�q�行传输。通常发送文件的做法是，先调用CreateFile()打开一个文�Ӟ��然后不断循环调用ReadFile() 和W(xu��)SASend ()直至数据发送完毕。但是这�U�方法很没有效率�Q�因为每�ơ调用ReadFile() �?WSASend ()都会(x��)涉及(qi��ng)一�ơ从用户模式到内核模式的转换。如果换成TransmitFile()�Q�那么只需要给它一个已打开文�g的句柄和要发送的字节敎ͼ�而所涉及(qi��ng)的模式�{换操作将只在调用CreateFile()打开文�g时发生一�ơ，然后TransmitFile()时再发生一�ơ。这��h��率就高多了�?/p>
TransmitPackets()比TransmitFile()更进一步，它允许用户只调用一�ơ就可以发送指定的多个文�g和内存缓冲区。函数原型如下：(x��)

BOOL TransmitPackets( SOCKET hSocket, LPTRANSMIT_PACKET_ELEMENT lpPacketArray, DWORD nElementCount, DWORD nSendSize, LPOVERLAPPED lpOverlapped, DWORD dwFlags );
其中�Q�lpPacketArray是一个结构的数组�Q�其中的每个元素既可以是一个文件句柄或者内存缓冲区�Q�该�l�构定义如下�Q?br>
typedef struct _TRANSMIT_PACKETS_ELEMENT { DWORD dwElFlags; DWORD cLength; union { struct { LARGE_INTEGER nFileOffset; HANDLE hFile; }; PVOID pBuffer; }; } TRANSMIT_FILE_BUFFERS;
其中各字�D�|��自描�q�型�?self explanatory)�?br>dwElFlags字段�Q�指定当前元素是一个文件句柄还是内存缓冲区(分别通过帔R��TF_ELEMENT_FILE 和TF_ELEMENT_MEMORY指定)�Q?br>cLength字段�Q�指定将从数据源发送的字节�?如果是文�Ӟ��q�个字段��gؓ(f��)0表示发送整个文�?�Q?br>�l�构中的无名联合体：(x��)包含文�g句柄的内存缓冲区(以及(qi��ng)可能的偏�U�量)�?
使用�q�两个API的另一个好处，是可以通过指定TF_REUSE_SOCKET和TF_DISCONNECT标志来重用套接字句柄。每当API完成数据的传输工作后�Q�就�?x��)在传输层��别断开�q�接�Q�这栯��个套接字��又可以重新提供�l�AcceptEx()使用。采用这�U�优化的�Ҏ(gu��)��~�程�Q�将减轻那个专门做接受操作的�U�程创徏套接字的压力(前文�q�及(qi��ng))�?/p>
�q�两个API也都有一个共同的��q��Q�Windows NT Workstation �?Windows 2000 专业版中�Q�函数每�ơ只能处理两个调用请求，只有在Windows NT、Windows 2000服务器版、Windows 2000高��服务器版�?Windows 2000 Data Center中才获得完全支持�?/p>
攑֜�一��L(f��ng)��?/strong>

以上各节中，我们讨论了开发高性能的、大响应规模的应用程序所需的函数、方法和可能遇到的资源瓶颈问题。这些对你意味着什么呢�Q�其实，�q�取决于你如何构造你的服务器和客��L(f��ng)��。当你能够在服务器和客户端设计上�q�行更好地控制时�Q�那么你��能够避开瓉��问题�?/p>
来看一个示范的环境。我们要设计一个服务器来响应客��L(f��ng)��的连接、发送请求、接收数据以�?qi��ng)断开�q�接。那么，服务器将需要创��Z��个监听套接字�Q�把它与某个完成端口�q�行兌��Q��ؓ(f��)每颗CPU创徏一个工作线�E�。再创徏一个线�E�专门用来发出AcceptEx()。我们知道客��L(f��ng)��?x��)在发出�q�接��h��后立��M��送数据，所以如果我们准备好接收�~�冲��Z��(x��)使事情变得更为容易。当�Ӟ��不要忘记不时地轮询AcceptEx()调用中��用的套接�?使用SO_CONNECT_TIME选项参数)来确保没有恶意超时的�q�接�?/p>
该设计中有一个重要的问题要考虑�Q�我们应该允许多��个AcceptEx()�q�行守候。这是因为，每发��Z��个AcceptEx()时我们都同时需要�ؓ(f��)它提供一个接收缓冲区�Q�那么内存中��会(x��)出现很多被锁定的��面(前文说过了，每个重叠操作都会(x��)消耗一��部分未分页内存池，同时�q�会(x��)锁定所有涉�?qi��ng)的�~�冲�?。这个问题很隑֛��{�，没有一个确切的�{�案。最好的�Ҏ(gu��)��是把�q�个值做成可以调整的�Q�通过反复做性能��试�Q�你��可以得出在典型应用环境中最佳的倹{�?/p>
好了�Q�当你测��清楚后�Q�下面就是发送数据的问题了，考虑的重�Ҏ(gu��)��你希望服务器同时处理多少个�ƈ发的�q�接。通常情况下，服务器应该限制�ƈ发连接的数量以及(qi��ng)�{�候处理的发送调用。因为�ƈ发连接数量越多，所消耗的未分��内存池也越多；�{�候处理的发送调用越多，被锁定的内存��面也越�?��心别超�q�了极限)。这同样也需要反复测试才知道�{�案�?/p>
对于上述环境�Q�通常不需要关闭单个套接字的缓冲区�Q�因为只在AcceptEx()中有一�ơ接收数据的操作�Q�而要保证�l�每个到来的�q�接提供接收�~�冲区�ƈ不是太难的事情。但是，如果客户��Z��服务器交互的方式变一变，客户机在发送了一�ơ数据之后，�q�需要发送更多的数据�Q�在�q�种情况下关闭接收缓冲就不太妙了�Q�除非你惛_��法保证在每个�q�接上都发出了重叠接收调用来接收更多的数据�?/p>
�l�论

开发大响应规模的Winsock服务器�ƈ不是很可怕，其实也就是设�|�一个监听套接字、接受连接请求和�q�行重叠收发调用。通过讄��合理的进行守候的重叠调用的数量，防止出现未分��内存池被耗尽�Q�这才是最主要的挑战。按照我们前面讨论的一些原则，你就可以开发出大响应规模的服务器应用程序�?br>

jay 2007-04-19 14:05 发表评论

Overlapped I/O

jay — Tue, 10 Apr 2007 10:06:00 GMT
重叠I/O也是一�U�异步I/O,同样也支持Win32的其它对�?当然在Winsock中可以发挥很大的作用。��用Overlapped开发支持一定数量的Socket的应用，效率是相当很高的。但��我个�h的观点，在Win32下做�|�络应用的开发，如果要支�?00个以上的Socket的话�Q�还是考虑Completion Port I/O。要求支持Socket最好是100个以下，我是��Z��q�样考虑的：(x��)Overlapped是通过多线�E�支持多Socket的，如果开辟的�U�程太多的话�Q�势必媄响了�pȝ��的性能�Q�Completion Port I/O可以更好支持大量的客��L(f��ng)��。这两种在Windows下具有高效率的I/O都不支持Windows CE�?qi��ng)其它��^台。我在这里说一下在开发网�l�应用时什么时候用Overlapped I/O 模型�Q�准备在Win98和以上版本或WinNT3.1和以上版本做开发，且要求支持Socket最好在100个以下。另外在串口开发中�Q�考虑效率问题�Q�有很多地方用到了Overlapped I/O�?br>         Overlapped I/O主要涉及(qi��ng)一个数据结构Overlapped(Winsock中是WSAOverlapped)和一个函数WSAGetOverlappedResult(..)�?br>         Overlapped I/O执行步骤很清晎ͼ�只要下面三步�Q?br>         (1) 应用先通过WSASend或WSARecv(不知道有没有其它的请求，我只用过�q�两个函�?�Q�注意要向两者�{入WSAOverlapped参数�Q?br>表示�Q�执行的是Overlapped操作�Q?br>         (2)在一个��@环中�Q�调用GetOverlappedResult(..)�{�待操作完成�Q�GetOverlappedResult�q�回�Ӟ��q�行相应的处理，如处理数据；
         (3) 最后，�q�在(2)循环中，发送另外一个请�?WSASend或WSARecv),重复处理(2)�?3)两步�?br>        �W�一步中执行W(xu��)SASend或WSARecv�Ӟ��函数立即�q�回�Q�得到SOCKET_ERROR信息且此时WSAGetErrorLast�q�回WSA_IO_PENDING�Q�说明调用已成功�Q�W(xu��)insock正在处理WSASend或WSARecv的请求。个��为Winsock在内部开辟了新的�U�程处理�Q�应用程序不用管理多�U�程�Q�达到异步的目的�Q�有利于性能的提高。WSASend或WSARecv也可能返�?0"�Q�表�C�立��x��功，�q�时�Q�应用还是可以在WSAGetOverlappedResult()处等待，处理�q�程与上面是一��L(f��ng)��Q�也��是说我们不��要马上在WSASend或WSARecv�q�行相关的处理�?br>       WSAGetOverlappedResult�q�回FASLE且WSAGetLastError�q�回WSA_IO_INCOMPLETE�Q�表�C�处理正在进行中�?nbsp;
        下面我给出支持单个Socket�?qi��ng)支持多个Socket的Console�E�序代码。先来看看支持单个Socket的程�?考虑��C��码简�z�性，只给一个框�Ӟ��同时不进行出错处理�?br>int main()
{
          WSAOVERLAPPED     Overlapped;

          // 启动Winsock�?qi��ng)徏立监听套接�?br>           listen(hListenSocket, 5);

          hClientSocket   =   accept(hListenSocket, NULL,   NULL);
          ZeroMemory(&Overlapped,   sizeof(WSAOVERLAPPED));

          nResult = WSARecv(...);    // 发出��h��

          for (; ;)
          {
                  bResult = WSAGetOverlappedResult(...);
                   // 函数�q�回后进行相应的处理
                   nResult =   WSARecv(...); // 发出另外一个请�?br>          }
}
        上面的程序只是想说明一下过�E�，�E�序没有实现什么功能。这样做的目的是节约字数�Q�用来说明我下面支持多个Socket的Console应用。请�l�箋看�?br>       先看一个自定义的结构体�Q�单句柄数据�l�构�Q�通过该结�?�ȝ��E�与某个特定的子�U�程中的套接字相互联�p�R�?br>         typedef struct   _PER_HANDLE_DATA
         {
                  SOCKET   hSocket;     // 主键:通信套接�?br>                  char   szClientIP[16];// 自定义字�D?客户端地址
                  int nOperateType;   // 自定义字�D?操作�c�d��
         }PER_HANDLE_DATA,   FAR* LPPER_HANDLE_DATA;
         在上面的�l�构中还可以加入自己需要的字段。在我下面的例子�E�序中，szClientIP是用来保存连接上来的客户端的IP的，�q�样在主�U�程��这个结构体传给子线�E�后�Q�在子线�E�中�Ҏ(gu��)��客户端IP��q��道目前处理的是哪个客��L(f��ng)��了。下面是�E�序的大部分�Q�同样除��M��些简单的出错输出�?br>#define     LISTEN_PORT 5000
#define     DATA_BUFSIZE 8192
#define     POST_RECV 0X01
#define     POST_SEND 0X02

int   main( )
{
          LPPER_HANDLE_DATA    lpPerHandleData;
           SOCKET               hListenSocket;
           SOCKET               hClientSocket;
           SOCKADDR_IN          ClientAddr;
           int                  nAddrLen;
          HANDLE               hThread;

          // Start WinSock and create a listen socket.

          listen(hListenSocket, 5);
          for (; ;)
         {
                  nAddrLen = sizeof(SOCKADDR);
                  hClientSocket = accept(hListenSocket, (LPSOCKADDR)&ClientAddr, &nAddrLen);

                  lpPerHandleData = (LPPER_HANDLE_DATA)malloc(sizeof(PER_HANDLE_DATA));
                 lpPerHandleData->hSocket = hClientSocket;
                  // 注意�q�里��连接的客户端的IP地址�Q�保存到了lpPerHandleData字段中了
                 strcpy(lpPerHandleData->szClientIP, inet_ntoa(ClientAddr.sin_addr));

                 // 为本�ơ客戯��求��生子�U�程
                 hThread = CreateThread(
                          NULL,
                           0,
                           OverlappedThread,
                           lpPerHandleData,   // ��lpPerHandleData传给子线�E?br>                           0,
                           NULL
                  );
                 CloseHandle(hThread);
         }
return 0;
}

DWORD WINAPI   OverlappedThread(LPVOID    lpParam)
{
           LPPER_HANDLE_DATA     lpPerHandleData = (LPPER_HANDLE_DATA)lpParam;
           WSAOVERLAPPED Overlapped;
           WSABUF        wsaBuf;
            char          Buffer[DATA_BUFSIZE];
            BOOL          bResult;
            int           nResult;

           ZeroMemory(&Overlapped, sizeof(WSAOVERLAPPED));
           wsaBuf.buf = Buffer;
            wsaBuf.len = sizeof(Buffer);
            lpPerHandleData->nOperateType = POST_RECV;     // 记录本次操作是Recv(..)

           dwFlags = 0;
           nResult = WSARecv(
                      lpPerHandleData->hSocket,   // Receive socket
                      &wsaBuf,                                  // 指向WSABUF�l�构的指�?br>                      1,                                                 // WSABUF数组的个�?br>                      &dwNumOfBytesRecved,      // 存放当WSARecv完成后所接收到的字节�?br>                      &dwFlags,                                 // A pointer to flags
                     &Overlapped,                           // A pointer to a WSAOVERLAPPED structure
                      NULL                                         // A pointer to the completion routine,this is NULL
           );
          if ( nResult   == SOCKET_ERROR    &&   GetLastError() !=       WSA_IO_PENDING)
         {
                 printf("WSARecv(..) failed.\n");
                 free(lpPerHandleData);
                 return 1;
          }

        while (TRUE)
         {
                 bResult = WSAGetOverlappedResult(
                        lpPerHandleData->hSocket,
                        &Overlapped,
                        &dwBytesTransferred,       // 当一个同步I/O完成�?接收到的字节�?br>                      TRUE,                      // �{�待I/O操作的完�?
                       &dwFlags
                 );
                if (bResult == FALSE && WSAGetLastError() != WSA_IO_INCOMPLETE)
               {
                        printf("WSAGetOverlappdResult(..) failed.\n");
                         free(lpPerHandleData);
                         return 1;   // 错误退�?br>                }

                if (dwBytesTransferred == 0)
                {
                           printf("客户端已退�?��断开与之的连�?\n");
                         closesocket(lpPerHandleData->hSocket);
                         free(lpPerHandleData);
                         break;
                }

                 // 在这里将接收到的数据�q�行处理
               printf("Received from IP: %s.\ndata: %s\n", lpPerHandleData->szClientIP, wsaBuf.buf);

               // 发送另外一个请求操�?br>               ZeroMemory(&Overlapped, sizeof(WSAOVERLAPPED));
               lpPerHandleData->nOperateType = POST_RECV;

              dwFlags = 0;
               nResult = WSARecv(...);
                if (...){}

        }

         return 0;
}
        �E�序�l�构比较清晰�Q�lpPerHandleData是主�U�程与子�U�程联系的纽带，子线�E�是通过�q�个�l�构获得所处理客户端的情况的。在不同的应用中可以��这个结构定义成不同的�Ş式，以符合所实现应用的需要。注意结构体的nOperateType在GetOverlappedResult�q�回时用�?可以�Ҏ(gu��)��q�个字段��定我们下一步的操作。请朋友们多提意见了�?/font>

jay 2007-04-10 18:06 发表评论

jay — Sat, 10 Mar 2007 09:51:00 GMT

摘自《Networking Programming for Microsoft Windows》第八章

“完成端口”模型是�q�今为止最为复杂的一�U�I/O模型。然而，假若一个应用程序同旉��要管理�ؓ(f��)��C��多的套接字，那么采用�q�种模型�Q�往往可以辑ֈ�最佳的�pȝ��性能�Q?/p>
从本质上��_(d��)��完成端口模型要求我们创徏一个Win32完成端口对象�Q�通过指定数量的线�E�，寚w��叠I/O��h��q�行��理�Q�以便�ؓ(f��)已经完成的重叠I/O��h��提供服务�?/p>
使用�q�种模型之前�Q�首先要创徏一个I/O完成端口对象�Q�用它面向�Q意数量的套接字句柄，��理多个I/O��h��。要做到�q�一点，需要调用CreateCompletionPort函数�?br />该函数定义如下：(x��)

HANDLE CreateIoCompletionPort(
    HANDLE FileHandle,
    HANDLE ExistingCompletionPort,
    ULONG_PTR CompletionKey,
    DWORD NumberOfConcurrentThreads
);

在我们深入探讨其中的各个参数之前�Q�首先要注意该函数实际用于两个明显有别的目的�Q?br />1. 用于创徏一个完成端口对象�?br />2. ��一个句柄同完成端口兌��C��赗��?

最开始创��Z��个完成端口时�Q�唯一感兴��的参数便是NumberOfConcurrentThreads�Q��ƈ发线�E�的数量�Q�；前面三个参数都会(x��)被忽略。NumberOfConcurrentThreads参数的特�D�之处在于，它定义了在一个完成端口上�Q�同时允许执行的�U�程数量。理��x��况下�Q�我们希望每个处理器各自负责一个线�E�的�q�行�Q��ؓ(f��)完成端口提供服务�Q�避免过于频�J�的�U�程“场景”切换。若��该参数设�ؓ(f��)0�Q�表明系�l�内安装了多��个处理器，便允许同时运行多��个�U�程�Q�可用下�q�C��码创��Z��个I/O完成端口�Q?/p>

hIOCP = CreateIoCompletionPort(INVALID_HANDLE_VALUE, NULL, 0, 0);

该语句的作用是返回一个句柄，在�ؓ(f��)完成端口分配了一个套接字句柄后，用来寚w��个端口进行标定（引用�Q��?

一、工作者线�E�与完成端口
成功创徏一个完成端口后�Q�便可开始将套接字句柄与对象兌��C��赗��但在关联套接字之前�Q�首先必��d��Z��个或多个“工作者线�E�”，以便在I/O��h��投递给完成端口对象后，为完成端口提供服务。在�q�个时候，大家或许�?x��)觉得奇怪，到底应创建多��个�U�程�Q�以便�ؓ(f��)完成端口提供服务呢？�q�实际正是完成端口模型显得颇为“复杂”的一个方面，因�ؓ(f��)服务I/O��h��所需的数量取决于应用�E�序的��M��设计情况。在此要��C��的一个重点在于，在我们调用CreateIoCompletionPort时指定的�q�发�U�程数量�Q�与打算创徏的工作者线�E�数量相比，它们代表的�ƈ非同一件事情。早些时候，我们曑־�议大家用CreateIoCompletionPort函数为每个处理器
都指定一个线�E�（处理器的数量有多��，便指定多��线�E�）以避免由于频�J�的�U�程“场景”交换活动，从而媄响系�l�的整体性能。CreateIoCompletionPort函数的NumberOfConcurrentThreads参数明确指示�pȝ��Q�在一个完成端口上�Q�一�ơ只允许n个工作者线�E�运行。假如在完成端口上创建的工作者线�E�数量超出n个，那么在同一时刻�Q�最多只允许n个线�E�运行。但实际上，在一�D�较短的旉��内，�pȝ��有可能超�q�这个��|��但很快便�?x��)把它减��至事先在CreateIoCompletionPort函数中设定的倹{��那么，��Z��实际创徏的工作者线�E�数量有时要比CreateIoCompletionPort函数讑֮�的多一些呢�Q�这样做有必要吗�Q�如先前所�q�ͼ��q�主要取决于
应用�E�序的��M��设计情况。假定我们的某个工作者线�E�调用了一个函敎ͼ�比如Sleep或WaitForSingleObject�Q�但却进入了暂停�Q�锁定或挂�v�Q�状态，那么允许另一个线�E�代替它的位�|�。换�a�之，我们希望随时都能执行��可能多的线�E�；当然�Q�最大的�U�程数量是事先在CreateIoCompletionPort调用里设定好的。这样一来，假如事先预计到自��q��U�程有可能暂时处于停��状态，那么最好能够创建比CreateIoCompletionPort的NumberOfConcurrentThreads参数的值多的线�E�，以便到时候充分发挥系�l�的潜力。一旦在完成端口上拥有��够多的工作者线�E�来为I/O��h��提供服务�Q�便可着手将套接字句柄同完成端口兌��C��赗��这要求我们在一个现有的完成端口上，调用CreateIoCompletionPort函数�Q�同时�ؓ(f��)前三个参数——FileHandle�Q�ExistingCompletionPort和CompletionKey——提供套接字的信息。其中， FileHandle参数指定一个要同完成端口关联在一��L(f��ng)��套接字句柄。ExistingCompletionPort参数指定的是一个现有的完成端口。CompletionKey�Q�完成键�Q�参数则指定要与某个特定套接字句柄关联在一��L(f��ng)��“单句柄数据”；在这个参��C��Q�应用程序可保存与一个套接字对应的�Q意类型的信息。之所以把它叫作“单句柄数据”，是由于它只对
应着与那个套接字句柄兌��在一��L(f��ng)��数据。可��其作�ؓ(f��)指向一个数据结构的指针�Q�来保存套接字句柄；在那个结构中�Q�同时包含了套接字的句柄�Q�以�?qi��ng)与那个套接字有关的其他信息�?/p>
�Ҏ(gu��)��我们到目前�ؓ(f��)止学到的东西�Q�首先来构徏一个基本的应用�E�序框架。下面阐�q�C��如何使用完成端口模型�Q�来开发一个ECHO服务器应用。在�q�个�E�序中，我们基本上按下述步骤行事�Q?/p>
1) 创徏一个完成端口。第四个参数保持�?�Q�指定在完成端口上，每个处理器一�ơ只允许执行一个工作者线�E��?br />2) 判断�pȝ��内到底安装了多少个处理器�?br />3) 创徏工作者线�E�，�Ҏ(gu��)��步骤2)得到的处理器信息�Q�在完成端口上，为已完成的I/O��h��提供服务�?br />4) 准备好一个监听套接字�Q�在端口5150上监听进入的�q�接��h��?br />5) 使用accept函数�Q�接受进入的�q�接��h��?br />6) 创徏一个数据结构，用于容纳“单句柄数据”，同时在结构中存入接受的套接字句柄�?br />7) 调用CreateIoCompletionPort�Q�将自accept�q�回的新套接字句柄同完成端口兌��C��赗��通过完成键（CompletionKey�Q�参敎ͼ��单句柄数据�l�构传递给C(j��)reateIoCompletionPort�?br />8) 开始在已接受的�q�接上进行I/O操作。在此，我们希望通过重叠I/O机制�Q�在新徏的套接字上投递一个或多个异步WSARecv或WSASend��h��。这些I/O��h��完成后，一个工作者线�E�会(x��)为I/O��h��提供服务�Q�同时��l�处理未来的I/O��h��Q�稍后便�?x��)在步�? )指定的工作者例�E�中�Q�体验到�q�一炏V�?br />9) 重复步骤5 ) ~ 8 )�Q�直��x��务器中止�?/p>
二、完成端口和重叠I/O
��套接字句柄与一个完成端口关联在一起后�Q�便可以套接字句柄�ؓ(f��)基础�Q�投递发送与接收��h��Q�开始对I/O��h��的处理。接下来�Q�可开始依赖完成端口，来接收有关I/O操作完成情况的通知。从本质上说�Q�完成端口模型利用了Win32重叠I/O机制。在�q�种机制中，象WSASend和W(xu��)SARecv�q�样的Winsock API调用�?x��)立卌��回。此�Ӟ��需要由我们的应用程序负责在以后的某个时��_(d��)��通过一个OVERLAPPED�l�构�Q�来接收调用的结果。在完成端口模型中，要想做到�q�一点，需要��用GetQueuedCompletionStatus�Q�获取排队完成状态）函数�Q�让一个或多个工作者线�E�在完成端口上等待。该函数的定义如下：(x��)

BOOL GetQueuedCompletionStatus(
    HANDLE CompletionPort,
    LPDWORD lpNumberOfBytes,
    PULONG_PTR lpCompletionKey,
    LPOVERLAPPED* lpOverlapped,
    DWORD dwMilliseconds
);

其中�Q�CompletionPort参数对应于要在上面等待的完成端口。lpNumberOfBytes参数负责在完成了一�ơI/O操作后（如WSASend或WSARecv�Q�，接收实际传输的字节数。lpCompletionKey参数为原先传递进入CreateIoCompletionPort函数的套接字�q�回“单句柄数据”。如我们早先所�q�ͼ�大家最好将套接字句柄保存在�q�个“键”（Key�Q�中。lpOverlapped参数用于接收完成的I/O操作的重叠结果。这实际是一个相当重要的参数�Q�因为可用它获取每个I/O操作的数据。而最后一个参敎ͼ�dwMilliseconds�Q�用于指定调用者希望等待一个完成数据包在完成端口上出现的时间。假如将其设为INFINITE�Q�调用会(x��)无休止地�{�待下去�?

三、单句柄数据和单I/O操作数据
一个工作者线�E�从GetQueuedCompletionStatus�q�个API调用接收到I/O完成通知后，在lpCompletionKey和lpOverlapped参数中，�?x��)包含一些必要的套接字信息。利用这些信息，可通过完成端口�Q��l�在一个套接字上的I/O处理。通过�q�些参数�Q�可获得两方面重要的套接字数据：(x��)单句柄数据，以及(qi��ng)单I/O操作数据。其中，lpCompletionKey参数包含了“单句柄数据”，因�ؓ(f��)在一个套接字首次与完成端口关联到一��L(f��ng)��时候，那些数据便与一个特定的套接字句柄对应�v来了。这些数据正是我们在�q�行CreateIoCompletionPort API调用的时候，通过CompletionKey参数传递的。如早先所�q�ͼ�应用�E�序可通过该参��C��递�Q意类型的数据。通常情况下，应用�E�序�?x��)将与I/O��h��有关的套接字句柄保存在这里。lpOverlapped参数则包含了一个OVERLAPPED�l�构�Q�在它后面跟随“单I/O操作数据”。我们的工作者线�E�处理一个完成数据包�Ӟ��数据原��不动打转回去，接受�q�接�Q�投递另一个线�E�，�{�等�Q�，�q�些信息是它必须要知道的。单I/O操作数据可以是追加到一个OVERLAPPED�l�构末尾的、�Q意数量的字节。假如一个函数要求用��C��个OVERLAPPED�l�构�Q�我们便必须��这��L(f��ng)��一个结构传递进去，以满��_��的要求。要惛_��到这一点，一个简单的�Ҏ(gu��)��是定义一个结构，然后��OVERLAPPED�l�构作�ؓ(f��)新结构的�W�一个元素��用。�D个例子来��_(d��)��可定义下�q�数据结构，实现对单I/O操作数据的管理：(x��)

typedef struct
{
    OVERLAPPED Overlapped;
    WSABUF     DataBuf;
    CHAR       Buffer[DATA_BUFSIZE];
    BOOL       OperationType;
}PER_IO_OPERATION_DATA

该结构演�C�Z��通常要与I/O操作兌��在一��L(f��ng)��某些重要数据元素�Q�比如刚才完成的那个I/O操作的类型（发送或接收��h��Q�。在�q�个�l�构中，我们认�ؓ(f��)用于已完成I/O操作的数据缓冲区是非常有用的。要惌��用一个Winsock API函数�Q�同时�ؓ(f��)其分配一个OVERLAPPED�l�构�Q�既可将自己的结构“造型”�ؓ(f��)一个OVERLAPPED指针�Q�亦可简单地撤消对结构中的OVERLAPPED元素的引用。如下例所�C�：(x��)

PER_IO_OPERATION_DATA PerIoData;
// 可像下面�q�样调用一个函�?br /> WSARecv(socket, ..., (OVERLAPPED *)&PerIoData);
// 或像�q�样
WSARecv(socket, ..., &(PerIoData.Overlapped));

在工作线�E�的后面部分�Q�等GetQueuedCompletionStatus函数�q�回了一个重叠结构（和完成键�Q�后�Q�便可通过撤消对OperationType成员的引用，调查到底是哪个操作投递到了这个句柄之上（只需��返回的重叠�l�构造型��q��PER_IO_OPERATION_DATA�l�构�Q�。对单I/O操作数据来说�Q�它最大的一个优点便是允许我们在同一个句柄上�Q�同时管理多个I/O操作�Q�读/写，多个读，多个写，�{�等�Q�。大家此时或�怼�(x��)产生�q�样的疑问：(x��)在同一个套接字上，真的有必要同时投递多个I/O操作吗？�{�案在于�pȝ��的“�׾~�性”，或者说“扩展能力”。例如，假定我们的机器安装了多个中央处理器，每个处理器都在运行一个工作者线�E�，那么在同一个时
候，完全可能有几个不同的处理器在同一个套接字上，�q�行数据的收发操作�?

最后要注意的一处细节是如何正确地关闭I/O完成端口—特别是同时�q�行了一个或多个�U�程�Q�在几个不同的套接字上执行I/O操作的时候。要避免的一个重要问题是在进行重叠I/O操作的同�Ӟ��释放一个OVERLAPPED�l�构。要想避免出现这�U�情况，最好的办法是针�Ҏ(gu��)��个套接字句柄�Q�调用closesocket函数�Q��Q何尚未进行的重叠I/O操作都会(x��)完成。一旦所有套接字句柄都已关闭�Q�便需在完成端口上�Q�终止所有工作者线�E�的�q�行。要惛_��到这一点，需要��用PostQueuedCompletionStatus函数�Q�向每个工作者线�E�都发送一个特�D�的完成数据包。该函数�?x��)指�C�每个线�E�都“立即结束�ƈ退出”。下面是PostQueuedCompletionStatus函数的定义：(x��)

BOOL PostQueuedCompletionStatus(
    HANDLE CompletionPort,
    DWORD dwNumberOfBytesTransferred,
    ULONG_PTR dwCompletionKey,
    LPOVERLAPPED lpOverlapped
);

其中�Q�CompletionPort参数指定惛_��其发送一个完成数据包的完成端口对象。而就dwNumberOfBytesTransferred、dwCompletionKey和lpOverlapped�q�三个参数来��_(d��)��每一个都允许我们指定一个��|��直接传递给GetQueuedCompletionStatus函数中对应的参数。这样一来，一个工作者线�E�收��C��递过来的三个GetQueuedCompletionStatus函数参数后，便可�Ҏ(gu��)��p��三个参数的某一个设�|�的�Ҏ(gu��)��|��军_��何时应该退出。例如，可用dwCompletionPort参数传�?��|��而一个工作者线�E�会(x��)��其解释成中止指令。一旦所有工作者线�E�都已关闭，便可使用CloseHandle函数�Q�关闭完成端口，最�l�安全退出程序�?/p>
注：(x��)CreateIoCompletionPort �Q�PostQueuedCompletionStatus �Q�GetQueuedCompletionStatus �{�函数的用法说明�?/p>
Platform SDK: Storage

I/O Completion Ports

I/O completion ports are the mechanism by which an application uses a pool of threads that was created when the application was started to process asynchronous I/O requests. These threads are created for the sole purpose of processing I/O requests. Applications that process many concurrent asynchronous I/O requests can do so more quickly and efficiently by using I/O completion ports than by using creating threads at the time of the I/O request.

I/O完成端口(s)是一�U�机�Ӟ��通过�q�个机制�Q�应用程序在启动时会(x��)首先创徏一个线�E�池�Q�然后该应用�E�序使用�U�程池处理异步I/O��h��。这些线�E�被创徏的唯一目的��是用于处理I/O��h��。对于处理大量�ƈ发异步I/O��h��的应用程序来��_(d��)��相比于在I/O��h��发生时创建线�E�来��_(d��)��使用完成端口(s)它就可以做的更快且更有效率�?

The CreateIoCompletionPort function associates an I/O completion port with one or more file handles. When an asynchronous I/O operation started on a file handle associated with a completion port is completed, an I/O completion packet is queued to the port. This can be used to combine the synchronization point for multiple file handles into a single object.

CreateIoCompletionPort函数�?x��)��一个I/O完成端口与一个或多个文�g句柄发生兌��。当与一个完成端口相关的文�g句柄上启动的异步I/O操作完成�Ӟ��一个I/O完成包就�?x��)进入到该完成端口的队列中。对于多个文件句柄来��_(d��)��可以把�q�些多个文�g句柄合�ƈ成一个单独的对象�Q�这个可以被用来�l�合同步点？

A thread uses the GetQueuedCompletionStatus function to wait for a completion packet to be queued to the completion port, rather than waiting directly for the asynchronous I/O to complete. Threads that block their execution on a completion port are released in last-in-first-out (LIFO) order. This means that when a completion packet is queued to the completion port, the system releases the last thread to block its execution on the port.

调用GetQueuedCompletionStatus函数�Q�某个线�E�就�?x��)等待一个完成包�q�入到完成端口的队列中，而不是直接等待异步I/O��h��完成。线�E�（们）��׃��(x��)��d��于它们的�q�行在完成端口（按照后进先出队列��序的被释放�Q�。这��意味着当一个完成包�q�入到完成端口的队列中时�Q�系�l�会(x��)释放最�q�被��d��在该完成端口的线�E��?

When a thread calls GetQueuedCompletionStatus, it is associated with the specified completion port until it exits, specifies a different completion port, or frees the completion port. A thread can be associated with at most one completion port.

调用GetQueuedCompletionStatus�Q�线�E�就�?x��)将会(x��)与某个指定的完成端口徏立联�p�，一直�g�l�其该线�E�的存在周期�Q�或被指定了不同的完成端口，或者释放了与完成端口的联系。一个线�E�只能与最多不��过一个的完成端口发生联系�?

The most important property of a completion port is the concurrency value. The concurrency value of a completion port is specified when the completion port is created. This value limits the number of runnable threads associated with the completion port. When the total number of runnable threads associated with the completion port reaches the concurrency value, the system blocks the execution of any subsequent threads that specify the completion port until the number of runnable threads associated with the completion port drops below the concurrency value. The most efficient scenario occurs when there are completion packets waiting in the queue, but no waits can be satisfied because the port has reached its concurrency limit. In this case, when a running thread calls GetQueuedCompletionStatus, it will immediately pick up the queued completion packet. No context switches will occur, because the running thread is continually picking up completion packets and the other threads are unable to run.

完成端口最重要的特性就是�ƈ发量。完成端口的�q�发量可以在创徏该完成端口时指定。该�q�发量限制了与该完成端口相关联的可运行线�E�的数目。当与该完成端口相关联的可运行线�E�的��L��目达��C��该�ƈ发量�Q�系�l�就�?x��)阻塞�Q何与该完成端口相兌��的后�l�线�E�的执行�Q�直��C��该完成端口相兌��的可�q�行�U�程数目下降到小于该�q�发量�ؓ(f��)止。最有效的假��x��发生在有完成包在队列中等待，而没有等待被满��Q�因为此时完成端口达��C��其�ƈ发量的极限。此�Ӟ��一个正在运行中的线�E�调用GetQueuedCompletionStatus�Ӟ��它就�?x��)立��M��队列中取走该完成包。这样就不存在着环境的切换，因�ؓ(f��)该处于运行中的线�E�就�?x��)连�l�不断地从队列中取走完成包，而其他的�U�程��׃��能运行了�?

The best value to pick for the concurrency value is the number of CPUs on the machine. If your transaction required a lengthy computation, a larger concurrency value will allow more threads to run. Each transaction will take longer to complete, but more transactions will be processed at the same time. It is easy to experiment with the concurrency value to achieve the best effect for your application.

对于�q�发量最好的挑选值就是�?zh��n)�计算��Z��cpu的数目。如果�?zh��n)�的事务处理需要一个�O长的计算旉��Q�一个比较大的�ƈ发量可以允许更多�U�程来运行。虽然完成每个事务处理需要花�Ҏ(gu��)��长的旉��Q�但更多的事务可以同时被处理。对于应用程序来��_(d��)��很容易通过��试�q�发量来获得最好的效果�?

The PostQueuedCompletionStatus function allows an application to queue its own special-purpose I/O completion packets to the completion port without starting an asynchronous I/O operation. This is useful for notifying worker threads of external events.

PostQueuedCompletionStatus函数允许应用�E�序可以针对自定义的专用I/O完成包进行排队，而无需启动一个异步I/O操作。这点对于通知外部事�g的工作者线�E�来说很有用�?

The completion port is freed when there are no more references to it. The completion port handle and every file handle associated with the completion port reference the completion port. All the handles must be closed to free the completion port. To close the port handle, call the CloseHandle function.

在没有更多的引用针对某个完成端口�Ӟ��需要释放该完成端口。该完成端口句柄以及(qi��ng)与该完成端口相关联的所有文件句柄都需要被释放。调用CloseHandle可以释放完成端口的句柄�?

jay 2007-03-10 17:51 发表评论