• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            大漠落日

            while(!dead) study++;
            posts - 46, comments - 126, trackbacks - 0, articles - 0
              C++博客 :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

            FileZilla Server源碼分析(2)

            Posted on 2010-06-03 17:31 亂78糟 閱讀(2615) 評論(0)  編輯 收藏 引用 所屬分類: 開源
            上一節講述的基本都是些做輔助的代碼,本節分析諸多socket類的父類CAsyncSocketEx和相關的Layer類。

            PS:拼音打字錯別字很多- -。

            從CAsyncSocketEx和CAsyncSocketExLayer類文件開頭注釋部分寫到:

            如何使用?
            -----------
            和MFC的CAsyncSocket非常像,如果不需要強化CAsyncSocket,那么在需要使用的時候只需替換掉CAsyncSocket即可。

            為什么這個類快一些?
            -------------------
            CAsyncSocketEx只是在分發通知事件消息的時候稍微快一點。
            首先來了解一下CAsyncSocket是如何工作的。對每個線程使用CAsyncSocket就會相應有一個窗口被創建。CAsyncSocket利用那個窗口的句柄調用WSAsyncSocket 。直到這兒,CAsyncSocket和它的工作方式是一樣的。但是CAsyncSocket對一個線程中的所有sockets僅使用一個windows消息(WM_SOCKET_NOTIFY)。當這個窗口收到 WM_SOCKET_NOTIFY 時,wParam參數包含socket句柄并且這個窗口使用map來查找一個CAsyncSocket實例。CAsyncSocketEx原理不同于此。它的輔助窗口(helper window)使用一定范圍內不同的window消息(WM_USER到OXBFFF)并且對每個socket傳遞不同的消息給WSAAsyncSelect,當這個指定范圍內消息被接收的時候,CAsyncSocketEx使用這個消息的索引減去WM_USER的值配合指向
            CAsyncSocketEx實例數組的指針來查找。如你所見,CAsyncSocketEx以更加高效的方式來使用輔助窗口,因為它不需要使用緩慢的maps來查找自己的實例。然后,速度增加的并不多,但是當同時使用大量的sockets的時候它的效果可能很明顯。

            請注意這個變動并沒有影響到原始數據吞吐效率,CAsyncSocketEx僅僅是分發通知消息的時候更加快速而已。

            CAsyncSocketEx還提供了什么?
            ---------------------------
            CAsyncSocketEx提供了一個靈活的層系統。一個例子就是代理層。創建一個代理層實例,配置并將其加入到CAsyncSocketEx實例的層鏈(layer chain),之后,你就能夠通過代理進行連接。
            好處:你不需要做很多變動就可以使用層系統。
            另一個層就是當前正在開發(注:目前已經完成,作者忘記修正這個注釋了)的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 函數添加一個層。
            成員變量m_pendingCallbacks保存的是所有等待被調用的回調信息。當WindowProc 參數message等于WM_USER+2的時候,調用OnLayerCallback, CAsyncSocketEx該虛成員函數僅做了清理工作,實際任務需要派生類去派生處理。

            相對于FD_READ作者又定義了#define FD_FORCEREAD (1<<15) 來跳過檢測是否有數據等待。現在用偽代碼描述一下WindowProc函數的工作:
            static LRESULT CALLBACK WindowProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
            {
               
            if (message>=WM_SOCKETEX_NOTIFY)
               {
                  
            //根據message-(WM_USER+3)的值查找socket,WM_USER+3 == WM_SOCKETEX_NOTIFY
                  if (!pSocket->m_pFirstLayer)
                      
            //分發通知消息,例如FD_READ,FD_CONNECT等
                   else
                      
            //分發通知消息給最底層,即 pSocket->m_pLastLayer->CallEvent(nEvent, nErrorCode);
                }
                
            else if (message == WM_USER)
                    
            //處理某一層發送的通知事件
                else if (message == WM_USER+1)
                    
            //通知連接的狀態,即調用虛函數OnConnect
                else if (message == WM_USER + 2)
                    
            //處理等待的回調信息
                else if (message == WM_TIMER)
                    
            //這種情況因為收到FD_CLOSE事件時仍然有數據未讀取,導致調用 pSocket->ResendCloseNotify()重發關閉消息,這個函數啟動了定時器。
                   
            //重發FD_CLOSE消息通知socket關閉
            }
            CAsyncSocketEx類中虛函數,如OnAcceptOnSendOn打頭的函數用于通知特定事件的發生狀態,派生類如果需要獲得這些狀態信息,就可以自己派生這些函數。

            全局的m_spAsyncSocketExThreadDataList則定義了一個t_AsyncSocketExThreadData(即分發線程)的鏈表,也就是說FileZilla可以有多個分發線程,每個分發線程對應多個socket,即CAsyncSocketEx。

            舉一個實際的場景:
            在FileZillaServer啟動時,缺省監聽了兩個端口:21和admin端口,因此就有兩個socket,即兩個CAsyncSocketEx。這兩個CAsyncSocketEx共用一個分發線程:t_AsyncSocketExThreadData
            當有用戶通過FTP連接上server并通過get/mget命令下載文件時,這時FTP服務器會啟動一個傳輸線程在一個臨時端口進行監聽,這時會增加一個CAsyncSocketEx,同時也增加一個負責這個CAsyncSocketEx的分發線程,因此m_spAsyncSocketExThreadDataList里也會增加一個結點。
            這時的狀況是:一個m_spAsyncSocketExThreadDataList鏈,兩個t_AsyncSocketExThreadData,三個 CAsyncSocketEx。

            下一節分析核心代碼。
            亚洲欧美一区二区三区久久| 97精品伊人久久大香线蕉app| 亚洲国产精品热久久| 99久久99久久精品国产| 久久精品无码一区二区三区日韩| 欧美性猛交xxxx免费看久久久| 久久天天躁狠狠躁夜夜avapp| 久久婷婷五月综合色高清| 亚洲成人精品久久| 2019久久久高清456| 7777久久亚洲中文字幕| 欧美激情精品久久久久久久九九九| 一本色道久久99一综合| 久久91这里精品国产2020| 久久精品国产99久久久古代| 久久福利青草精品资源站| 伊人久久大香线蕉无码麻豆| 久久亚洲AV成人无码国产| 久久国产影院| 久久久青草久久久青草| 一本一本久久A久久综合精品| 国产精品久久久天天影视香蕉| 亚洲精品无码久久久久去q | 国内精品久久久久久久久电影网| 亚洲伊人久久成综合人影院 | 亚洲国产二区三区久久| 国产aⅴ激情无码久久| 激情综合色综合久久综合| 久久精品国产亚洲AV无码娇色| 久久久精品人妻无码专区不卡| 久久免费视频观看| 久久超碰97人人做人人爱| 丁香色欲久久久久久综合网| 亚洲国产小视频精品久久久三级| 国产精品美女久久久久av爽| 69SEX久久精品国产麻豆| 一本色综合网久久| 久久久久亚洲AV无码专区体验| 亚洲女久久久噜噜噜熟女| 久久亚洲AV成人无码国产| 久久精品aⅴ无码中文字字幕重口|