分类: C/C++
2010-03-21 21:55:31
这个类的名字来源于MFC类CAsyncSocket,CAsyncSocketEx完全兼容于CAsyncSocket,在 CAsyncSocket上写的代码可以一字不动的在CAsyncSocketEx下编译通过,CAsyncSocketEx还做了一些功能上的扩展和性 能上的优化。
CAsyncSocketEx和另两个类CAsyncSocketExHelperWindow以及
CAsyncSocketExLayer紧密相关,CAsyncSocketExLayer的作用类似于J2EE中的Interceptor的作用,这里
可以先不讨论。
CAsyncSocketEx采用的是消息处理的机制,即监听的端口有活动,如有数据要接收、发送等,通过发送消息来实现这种信息的通讯,这里具体
到windows socket的API就是WSAAsyncSelect,它的原型是:
int WSAAsyncSelect(
SOCKET s,
HWND hWnd,
unsigned int wMsg,
long lEvent
);
Parameters
s
[in] Descriptor identifying the socket for which
event notification is required.
hWnd
[in] Handle identifying the
window that will receive a message when a network event occurs.
wMsg
[in] Message to be received when a network event occurs.
lEvent
[in] Bitmask that specifies a combination of network events in
which the application is interested.
简单地说,这个方法可以让windows在SOCKET s指定的socket上,当指定的事件lEvent发生时,发送消息wMsg到窗口hWnd。
由于windows的消息机制必须使用一个windows窗口,因此CAsyncSocketEx必须创建一个windows窗口来接收这种消息, 这就是类CAsyncSocketExHelperWindow的主要作用,当然这个窗口并不是必须被显示出来的,只要让系统知道有这个windows存 在(即有hWnd)就可以了。
在CAsyncSocketEx中,定义了一个static的链表:
static struct
t_AsyncSocketExThreadDataList
{
t_AsyncSocketExThreadDataList
*pNext;
t_AsyncSocketExThreadData *pThreadData;
}
*m_spAsyncSocketExThreadDataList;
这个链表维护了一个t_AsyncSocketExThreadData
链,看一下这个struct的定义:
struct t_AsyncSocketExThreadData
{
CAsyncSocketExHelperWindow
*m_pHelperWindow;
int nInstanceCount;
DWORD nThreadId;
std::list
} *m_pLocalAsyncSocketExThreadData;
看名称就知道,这是一
个与线程thread有关的结构,事实上这个结构描述了一个分发线程。
在FileZilla的实现中,整个静态的类关系是这样的:
一个CAsyncSocketEx代表了一个socket,即在某个端口进行监听的socket,如前面提到的标准的FTP 21端口、admin端口等等。
一个CAsyncSocketExHelperWindow代表了一个负责消息分发的线程,即负责接收到 socket(CAsyncSocketEx)的活动,然后分发到不同的处理类CAsyncSocketEx。每一个 CAsyncSocketExHelperWindow一一对应于一个分发线程,即一个分发线程只有一个 CAsyncSocketExHelperWindow,反之亦然。结构t_AsyncSocketExThreadData即描述了分发线程与 CAsyncSocketExHelperWindow的关系。
CAsyncSocketExHelperWindow可以为多个CAsyncSocketEx进行分发,而CAsyncSocketEx只能由一
个CAsyncSocketExHelperWindow进行分发。现在仔细研究一下结构t_AsyncSocketExThreadData:
struct
t_AsyncSocketExThreadData
{
CAsyncSocketExHelperWindow
*m_pHelperWindow; // 这个线程对应的CAsyncSocketExHelperWindow
int
nInstanceCount; // 当前分发线程对应了几个CAsyncSocketEx
DWORD nThreadId; //
当前线程的threadID
std::list
} *m_pLocalAsyncSocketExThreadData;
这段代码是在类CAsyncSocketEx
中定义的,即m_pLocalAsyncSocketExThreadData定义了当前CAsyncSocketEx所对应的分发线程,即
CAsyncSocketExHelperWindow。
全局的m_spAsyncSocketExThreadDataList则定义了一个t_AsyncSocketExThreadData(即分发 线程)的链表,也就是说FileZilla可以有多个分发线程,每个分发线程对应多个socket,即CAsyncSocketEx。
举一个实际的场景:
在FileZilla
Server启动时,缺省监听了两个端口:21和admin端口,因此就有两个socket,即两个CAsyncSocketEx。
这两个
CAsyncSocketEx共用一个分发线程:t_AsyncSocketExThreadData
当有用户通过FTP连接上server并通过get/mget命令下载文件时,这时FTP服务器会启动一个传输线程在一个临时端口进行监听,这时会 增加一个CAsyncSocketEx,同时也增加一个负责这个CAsyncSocketEx的分发线程,因此 m_spAsyncSocketExThreadDataList里也会增加一个结点。
这时的状况是:
一个m_spAsyncSocketExThreadDataList链,两个
t_AsyncSocketExThreadData,三个CAsyncSocketEx。
下面仔细分析具体的实现。