怎樣進行FileZilla的源代碼分析

本篇文章為大家展示了怎樣進行FileZilla的源代碼分析，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

FileZilla是一種快速、可信賴的FTP客戶端以及服務器端開放源代碼程式，具有多種特色、直覺的接口。今天就給大家分析下FileZilla的源代碼。

< type="text/javascript"> < src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript"> < type="text/javascript"> < src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript">

CServer在Create()時，通過CListenSocket來監聽標準的FTP 21端口，通過CAdminListenSocket來監聽admin端口(缺省是14147)，這兩個類都繼承于CAsyncSocketEx，這個類是FileZilla中所有socket處理的基類，搞清楚這個類可以清楚明白socket處理的機制。

這個類的名字來源于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 layerCloseNotify;

} *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 layerCloseNotify; // 這個以后再說

} *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。

上述內容就是怎樣進行FileZilla的源代碼分析，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。