在Winodows平台上,网络编程的主要接口就是WinSock,目前大多数的Windows平台上的WinSock平台已经升级到2.0版,简称为WinSock2。在WinSock2中扩展了很多很有用的Windows味很浓的SOCKET专用API,为Windows平台用户提供高性能的网络编程支持。这些函数中的大多数已经不再是标准的“Berkeley”套接字模型的API了。使用这些函数的代价就是你不能再将你的网络程序轻松的移植到“尤里平台”(我给Unix+Linux平台的简称)下,反过来因为Windows平台支持标准的“Berkeley”套接字模型,所以你可以将大多数尤里平台下的网络应用移植到Windows平台下。
如果不考虑可移植性(或者所谓的跨平台性),而是着重于应用的性能时,尤其是注重服务器性能时,对于Windows的程序,都鼓励使用WinSock2扩展的一些API,更鼓励使用IOCP模型,因为这个模型是目前Windows平台上比较完美的一个高性能IO编程模型,它不但适用于SOCKET编程,还适用于读写硬盘文件,读写和管理命名管道、邮槽等等。如果再结合Windows线程池,IOCP几乎可以利用当今硬件所有可能的新特性(比如多核,DMA,高速总线等等),本身具有先天的扩展性和可用性。
今天讨论的重点就是SOCKET池。很多VC程序员也许对SOCKET池很陌生,也有些可能很熟悉,那么这里就先讨论下这个概念。
在Windows平台上SOCKET实际上被视作一个内核对象的句柄,很多WindowsAPI在支持传统的HANDLE参数的同时也支持SOCKET,比如有名的CreateIoCompletionPort就支持将SOCKET句柄代替HANDLE参数传入并调用。熟悉Windows内核原理的读者,立刻就会发现,这样的话,我们创建和销毁一个SOCKET句柄,实际就是在系统内部创建了一个内核对象,对于Windows来说这牵扯到从Ring3层到Ring0层的耗时操作,再加上复杂的安全审核机制,实际创建和销毁一个SOCKET内核对象的成本还是蛮高的。尤其对于一些面向连接的SOCKET应用,服务端往往要管理n多个代表客户端通信的SOCKET对象,而且因为客户的变动性,主要面临的大量操作除了一般的收发数据,剩下的就是不断创建和销毁SOCKET句柄,对于一个频繁接入和断开的服务器应用来说,创建和销毁SOCKET的性能代价立刻就会体现出来,典型的例如WEB服务器程序,就是一个需要频繁创建和销毁SOCKET句柄的SOCKET应用。这种情况下我们通常都希望对于断开的SOCKET对象,不是简单的“销毁”了之(很多时候“断开”的含义不一定就等价于“销毁”,可以仔细思考一下),更多时候希望能够重用这个SOCKET对象,这样我们甚至可以事先创建一批SOCKET对象组成一个“池”,在需要的时候“重用”其中的SOCKET对象,不需要的时候将SOCKET对象重新丢入池中即可,这样就省去了频繁创建销毁SOCKET对象的性能损失。在原始的“Berkeley”套接字模型中,想做到这点是没有什么办法的。而幸运的是在Windows平台上,尤其是支持WinSock2的平台上,已经提供了一套完整的API接口用于支持SOCKET池。
对于符合以上要求的SOCKET池,首先需要做到的就是对SOCKET句柄的“回收”,因为创建函数无论在那个平台上都是现成的,而最早能够实现这个功能的WinSock函数就是TransmitFile,如果代替closesocket函数像下面这样调用就可以“回收”一个SOCKET句柄,而不是销毁:(注意“回收”这个功能对于TransmitFile函数来说只是个“副业”。)
TransmitFile(hSocket,NULL,0,0,NULL,NULL,TF_DISCONNECT |TF_REUSE_SOCKET );
注意上面函数的最后一个参数,使用了标志TF_DISCONNECT和TF_REUSE_SOCKET,第一个值表示断开,第二个值则明确的表示“重用”实际上也就是回收这个SOCKET,经过这个处理的SOCKET句柄,就可以直接再用于connect等操作,但是此时我们会发现,这个回收来的SOCKET似乎没什么用,因为其他套接字函数没法直接利用这个回收来的SOCKET句柄。
这时就要WinSock2的一组专用API上场了。我将它们按传统意义上的服务端和客户端分为两组:
一、
SOCKET WSASocket(
);
BOOL AcceptEx(
);
BOOL DisconnectEx(
);
二、
SOCKET WSASocket(
);
BOOL PASCAL ConnectEx(
);
BOOL DisconnectEx(
);
注意观察这些函数,似乎和传统的“Berkeley”套接字模型中的一些函数“大同小异”,其实仔细观察他们的参数,就已经可以发现一些调用他们的“玄机”了。
首先我们来看AcceptEx函数,与accept函数不同,它需要两个SOCKET句柄作为参数,头一个参数的含义与accept函数的相同,而第二个参数的意思就是accept函数返回的那个代表与客户端通信的SOCKET句柄,在传统的accept内部,实际在返回那个代表客户端的SOCKET时,是在内部调用了一个SOCKET的创建动作,先创建这个SOCKET然后再“accept”让它变成代表客户端连接的SOCKET,而AcceptEx函数就在这里“扩展”(实际上是“阉割”才对)accept函数,省去了内部那个明显的创建SOCKET的动作,而将这个创建动作交给最终的调用者自己来实现。AcceptEx要求调用者创建好那个sAcceptSocket句柄然后传进去,这时我们立刻发现,我们回收的那个SOCKET是不是也可以传入呢?答案是肯定的,我们就是可以利用这个函数传入那个“回收”来的SOCKET句柄,最终实现服务端的SOCKET重用。
这里需要注意的就是,AcceptEx函数必须工作在非阻塞的IOCP模型下,同时即使AcceptEx函数返回了,也不代表客户端连接进来或者连接成功了,我们必须依靠它的“完成通知”才能知道这个事实,这也是AcceptEx函数区别于accept这个阻塞方式函数的最大之处。通常可以利用AcceptEx的非阻塞特性和IOCP模型的优点,一次可以“预先”发出成千上万个AcceptEx调用,“等待”客户端的连接。对于习惯了accept阻塞方式的程序员来说,理解AcceptEx的工作方式还是需要费一些周折的。下面的例子就演示了如何一次调用多个AcceptEx:
//批量创建SOCKET,并调用对应的AcceptEx
for(UINT i = 0; i <1000; i++)
{//调用1000次
//创建与客户端通讯的SOCKET,注意SOCKET的创建方式
skAccept = ::WSASocket(AF_INET,
if (INVALID_SOCKET == skAccept)
{
}
//创建一个自定义的OVERLAPPED扩展结构,使用IOCP方式调用
pAcceptOL = newCGRSOverlappedData(GRS_OP_ACCEPT
,this,skAccept,NULL);
pAddrBuf =pAcceptOL->GetAddrBuf();
//4、发出AcceptEx调用
//注意将AcceptEx函数接收连接数据缓冲的大小设定成了0,这将导致此函数立即返回,虽然与
//不设定成0的方式而言,这导致了一个较低下的效率,但是这样提高了安全性,所以这种效率
//牺牲是必须的
if(!AcceptEx(m_skServer,
{
int iError = WSAGetLastError();
if( ERROR_IO_PENDING != iError
{
delete pAcceptOL;
}
}
以上的例子只是简单的演示了AcceptEx的调用,还没有涉及到真正的“回收重用”这个主题,那么下面的例子就演示了如何重用一个SOCKET句柄:
if(INVALID_SOCKET == skClient)
{
throwCGRSException(_T("SOCKET句柄是无效的!"));
}
On
CGRSOverlappedData*pData
= newGRSOverlappedData(GRS_OP_DISCONNECTEX
,this,skClient,pUseData);
//回收而不是关闭后再创建大大提高了服务器的性能
DisconnectEx(skClient,&pData->m_ol,TF_REUSE_SOCKET,0);
......
CGRSAddrbuf*pBuf = NULL;
pNewOL = newCGRSOverlappedData(GRS_OP_ACCEPT
,this,skClient,pUseData);
pBuf =pNewOL->GetAddrBuf();
//把这个回收的SOCKET重新丢进连接池
if(!AcceptEx(m_skServer,skClient,pBuf->m_pBuf,
{
int iError = WSAGetLastError();
}
//注意在这个SOCKET被重新利用后,重新与IOCP绑定一下,该操作会返回一个已设置的错误,这个错误直接被忽略即可
::BindIoCompletionCallback
,Server_IOCPThread, 0);
至此回收重用SOCKET的工作也就结束了,以上的过程实际理解了IOCP之后就比较好理解了,例子的最后我们使用了BindIoCompletionCallback
在上面的例子中,回收SOCKET句柄主要使用了DisconnectEx函数,而不是之前介绍的TransmitFile函数,为什么呢?因为TransmitFile函数在一些情况下会造成死锁,无法正常回收SOCKET,毕竟不是专业的回收重用SOCKET函数,我就遇到过好几次死锁,最后偶然的发现了DisconnectEx函数这个专用的回收函数,调用之后发现比TransmitFile专业多了,而且不管怎样都不会死锁。
最后需要补充的就是这几个函数的调用方式,不能像传统的SOCKETAPI那样直接调用它们,而需要使用一种间接的方式来调用,尤其是AcceptEx和DisconnectEx函数,下面给出了一个例子类,用于演示如何动态载入这些函数并调用之:
class CGRSMsSockFun
{
public:
CGRSMsSockFun(SOCKET skTemp =INVALID_SOCKET)
{
}
public:
virtual ~CGRSMsSockFun(void)
{
}
protected:
BOOL LoadWSAFun(SOCKET&skTemp,GUID&funGuid,void*&pFun)
{
bCreateSocket = (skTemp !=INVALID_SOCKET);
if(INVALID_SOCKET == skTemp)
}
protected:
LPFN_ACCEPTEX m_pfnAcceptEx;
LPFN_CONNECTEX m_pfnConnectEx;
LPFN_DISCONNECTEXm_pfnDisconnectEx;
LPFN_GETACCEPTEXSOCKADDRSm_pfnGetAcceptExSockaddrs;
LPFN_TRANSMITFILEm_pfnTransmitfile;
LPFN_TRANSMITPACKETSm_pfnTransmitPackets;
LPFN_WSARECVMSG m_pfnWSARecvMsg;
protected:
BOOL LoadAcceptExFun(SOCKET&skTemp)
{
,(void*&)m_pfnAcceptEx);
}
BOOL LoadConnectExFun(SOCKET&skTemp)
{
,(void*&)m_pfnConnectEx);
}
BOOLLoadDisconnectExFun(SOCKET&skTemp)
{
,(void*&)m_pfnDisconnectEx);
}
BOOL LoadGetAcceptExSockaddrs
{
= WSAID_GETACCEPTEXSOCKADDRS;
,(void*&)m_pfnGetAcceptExSockaddrs);
}
BOOLLoadTransmitFileFun(SOCKET&skTemp)
{
,(void*&)m_pfnTransmitfile);
}
BOOLLoadTransmitPacketsFun(SOCKET&skTemp)
{
,(void*&)m_pfnTransmitPackets);
}
BOOLLoadWSARecvMsgFun(SOCKET&skTemp)
{
,(void*&)m_pfnWSARecvMsg);
}
public:
BOOL LoadAllFun(SOCKET skTemp)
{//注意这个地方的调用顺序,是根据服务器的需要,并结合了表达式副作用
}
public:
GRS_FORCEINLINE BOOL AcceptEx (
{
}
GRS_FORCEINLINE BOOL ConnectEx(
{
}
GRS_FORCEINLINE BOOL DisconnectEx(
{
}
GRS_FORCEINLINE VOIDGetAcceptExSockaddrs (
{
}
GRS_FORCEINLINE BOOL TransmitFile(
{
}
GRS_FORCEINLINE BOOLTransmitPackets(
{
nSendSize,lpOverlapped,dwFlags
}
GRS_FORCEINLINE INT WSARecvMsg(
{
}
};
这个类的使用非常简单,只需要声明一个类的对象,然后调用其成员AcceptEx、DisconnectEx函数等即可,参数与这些函数的MSDN声明方式完全相同,除了本文中介绍的这些函数外,这个类还包含了很多其他的Winsock2函数,那么都应该按照这个类中演示的这样来动态载入后再行调用,如果无法载入通常说明你的环境中没有Winsock2函数库,或者是你初始化的不是2.0版的Winsock环境。
这个类是本人完整类库的一部分,如要使用需要自行修改一些地方,如果不知如何修改或遇到什么问题,可以直接跟帖说明,我会不定期回答大家的问题,这个类可以免费使用、分发、修改,可以用于任何商业目的,但是对于使用后引起的任何问题,本人概不负责,有问题请跟帖。关于AcceptEx以及其他一些函数,包括本文中没有介绍到得函数,我会在后续的一些专题文章中进行详细深入的介绍,敬请期待。如果你有什么疑问,或者想要了解什么也请跟帖说明,我会在后面的文章中尽量说明。
转: http://gamebabyrocksun.blog.163.com/blog/static/571534632010115104634310