Posted on 2010-06-03 17:31
亂78糟 閱讀(2631)
評論(0) 編輯 收藏 引用 所屬分類:
開源
上一節(jié)講述的基本都是些做輔助的代碼，本節(jié)分析諸多socket類的父類CAsyncSocketEx和相關的Layer類。
PS：拼音打字錯別字很多- -。
從CAsyncSocketEx和CAsyncSocketExLayer類文件開頭注釋部分寫到：
如何使用？-----------和MFC的CAsyncSocket非常像，如果不需要強化CAsyncSocket,那么在需要使用的時候只需替換掉CAsyncSocket即可。為什么這個類快一些？-------------------CAsyncSocketEx只是在分發(fā)通知事件消息的時候稍微快一點。首先來了解一下CAsyncSocket是如何工作的。對每個線程使用CAsyncSocket就會相應有一個窗口被創(chuàng)建。CAsyncSocket利用那個窗口的句柄調用WSAsyncSocket 。直到這兒，CAsyncSocket和它的工作方式是一樣的。但是CAsyncSocket對一個線程中的所有sockets僅使用一個windows消息（WM_SOCKET_NOTIFY）。當這個窗口收到 WM_SOCKET_NOTIFY 時，wParam參數(shù)包含socket句柄并且這個窗口使用map來查找一個CAsyncSocket實例。CAsyncSocketEx原理不同于此。它的輔助窗口（helper window）使用一定范圍內(nèi)不同的window消息（WM_USER到OXBFFF）并且對每個socket傳遞不同的消息給WSAAsyncSelect，當這個指定范圍內(nèi)消息被接收的時候，CAsyncSocketEx使用這個消息的索引減去WM_USER的值配合指向
CAsyncSocketEx實例數(shù)組的指針來查找。如你所見，CAsyncSocketEx以更加高效的方式來使用輔助窗口，因為它不需要使用緩慢的maps來查找自己的實例。然后，速度增加的并不多，但是當同時使用大量的sockets的時候它的效果可能很明顯。請注意這個變動并沒有影響到原始數(shù)據(jù)吞吐效率，CAsyncSocketEx僅僅是分發(fā)通知消息的時候更加快速而已。CAsyncSocketEx還提供了什么？---------------------------CAsyncSocketEx提供了一個靈活的層系統(tǒng)。一個例子就是代理層。創(chuàng)建一個代理層實例，配置并將其加入到CAsyncSocketEx實例的層鏈（layer chain），之后，你就能夠通過代理進行連接。好處：你不需要做很多變動就可以使用層系統(tǒng)。另一個層就是當前正在開發(fā)（注：目前已經(jīng)完成，作者忘記修正這個注釋了）的SSL層用來進行SSL加密連接。從作者的注釋中我們可以大致了解這些類的功能和原理，源碼我也僅挑若干個人比較感興趣的部分稍微分析一下。
CAsyncSocketEx類和cAsyncSocketExLayer類互為友元類。
CAsyncSocketEx類中有大量的
#ifndef NOLAYERS ... #endif ,FileZillaServer工程中沒有定義NOLAYERS，所以這些代碼都要被編譯。
#ifndef NOLAYERS
//Layer chain
CAsyncSocketExLayer *m_pFirstLayer;
CAsyncSocketExLayer *m_pLastLayer;
friend CAsyncSocketExLayer;
//Called by the layers to notify application of some events
virtual int OnLayerCallback(std::list<t_callbackMsg>& callbacks);
#endif //NOLAYERS
上面那一段代碼是為了構造了作者注釋中所說的層鏈，每個CAsyncSocketEx實例可以通過調用
AddLayer 函數(shù)添加一個層。
成員變量m_pendingCallbacks保存的是所有等待被調用的回調信息。當
WindowProc
參數(shù)message等于WM_USER+2的時候，調用
OnLayerCallback，
CAsyncSocketEx該虛成員函數(shù)僅做了清理工作，實際任務需要派生類去派生處理。
相對于FD_READ作者又定義了#define FD_FORCEREAD (1<<15)
來跳過檢測是否有數(shù)據(jù)等待。現(xiàn)在用偽代碼描述一下
WindowProc函數(shù)的工作：
static LRESULT CALLBACK WindowProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
if (message>=WM_SOCKETEX_NOTIFY)
{
//根據(jù)message-（WM_USER+3）的值查找socket，WM_USER+3 == WM_SOCKETEX_NOTIFY
if (!pSocket->m_pFirstLayer)
//分發(fā)通知消息，例如FD_READ,FD_CONNECT等
else
//分發(fā)通知消息給最底層，即 pSocket->m_pLastLayer->CallEvent(nEvent, nErrorCode);
}
else if (message == WM_USER)
//處理某一層發(fā)送的通知事件
else if (message == WM_USER+1)
//通知連接的狀態(tài)，即調用虛函數(shù)OnConnect
else if (message == WM_USER + 2)
//處理等待的回調信息
else if (message == WM_TIMER)
//這種情況因為收到FD_CLOSE事件時仍然有數(shù)據(jù)未讀取，導致調用 pSocket->ResendCloseNotify()重發(fā)關閉消息，這個函數(shù)啟動了定時器。
//重發(fā)FD_CLOSE消息通知socket關閉
}
CAsyncSocketEx類中虛函數(shù)，如
OnAccept，
OnSend等
On打頭的函數(shù)用于通知特定事件的發(fā)生狀態(tài)，派生類如果需要獲得這些狀態(tài)信息，就可以自己派生這些函數(shù)。
全局的
m_spAsyncSocketExThreadDataList則定義了一個
t_AsyncSocketExThreadData(即分發(fā)線程)的鏈表，也就是說FileZilla可以有多個分發(fā)線程，每個分發(fā)線程對應多個socket，即CAsyncSocketEx。
舉一個實際的場景：
在FileZillaServer啟動時，缺省監(jiān)聽了兩個端口：21和admin端口，因此就有兩個socket，即兩個CAsyncSocketEx。這兩個CAsyncSocketEx共用一個分發(fā)線程：
t_AsyncSocketExThreadData。
當有用戶通過FTP連接上server并通過get/mget命令下載文件時，這時FTP服務器會啟動一個傳輸線程在一個臨時端口進行監(jiān)聽，這時會增加一個CAsyncSocketEx，同時也增加一個負責這個CAsyncSocketEx的分發(fā)線程，因此
m_spAsyncSocketExThreadDataList里也會增加一個結點。
這時的狀況是：一個m_spAsyncSocketExThreadDataList鏈，兩個t_AsyncSocketExThreadData，三個 CAsyncSocketEx。
下一節(jié)分析核心代碼。