BT原始碼學習心得(六)：Tracing Service器(Tracker)的程式碼分析(初始化)

BT原始碼學習心得(六)：Tracing Service器(Tracker)的程式碼分析(初始化)
author:wolfenstein

    Tracker在BT中是一個很重要的部分。這個名詞我注意到以前的文章中都是直接引用，沒有翻譯過來，想了一下，決定把它翻譯成Tracing Service器。
    在BT下載中，種子檔案表明了要下載的檔案的資訊和對它進行檢查的訊息摘要碼，但是每個對等客戶(peer，以後我把peer全部翻譯成對等客戶，以區別client)要擷取其它對等客戶的資訊時，還是要和Tracing Service器聯絡的。Tracing Service器上面不儲存任何和種子所代表的內容有關的檔案，它只記錄所有下載該種子的機器的IP地址，連接埠等資訊，並在客戶向它請求是返回一些這樣的資訊列表，具體的實際內容，由對等客戶之間完成互動。
    Tracing Service器的代碼實現在BitTorrent/track.py中，在bttrack.py中只是很簡單得一行：
    track(argv[1:])
    這樣就把參數傳到track.py的track函數。track函數本身也比較簡單，處理參數和相關的設定檔，建立一個RawServer，然後用create_serversocket建立伺服器通訊端，然後開始服務。關於在BT中使用網路服務上次已經有很詳細地介紹，這裡不再重複。只是針對tracker函數的具體情況，分析一下運行到listen_forever後的情況，首先，建立了Tracker對象，開啟了在某個連接埠(config['port'])偵聽的網路服務，這個函數的處理對象是一個HTTPHandler。所以我們要剖析器的流程只需要先分析Tracker的初始化函數，看看它建立後都做了些什麼，然後再看HTTPHandler實際分析它的網路通訊協定。
    在Tracker對象的初始化函數中，首先還是對各種變數的初始化。然後要從一個狀態檔案中進行一些狀態恢複，也就是恢複state變數。這個變數中的值很重要，我們可以需要從一些地方來得知它的結構，狀態檔案的讀取和儲存出得不到它的資訊，因為這兩處的實現方式就是bencode和bdecode，只能保證無論state的結構是什麼都能合適得被儲存和恢複，由此又看出bencode編碼設計的巧妙。但是有一個函數對我們分析state的內部結構很有協助，那就是statefiletemplate，這個函數檢查state中的值是否合法，因此我們可以從這裡得到state的一些結構資訊。
    首先，state必須是一個字典類型的變數。然後檢查每一項的值。如果發現一項關鍵字是'peers'，那麼它的值必須也是一個字典，這個字典是一個以種子檔案的資訊部分的訊息摘要值為關鍵字的字典，由於sha摘要演算法比較好得滿足了摘要演算法的要求，即不同的種子檔案它們產生相同摘要的機率極小。而且由於這是由種子檔案的內容產生的摘要值，因此即使把種子檔案改名，還是可以識別出來是哪個種子檔案。因此'peers'的值可以看成是為每一個種子檔案記錄的資訊，那麼為每個種子檔案記錄的是什麼資訊呢？這個資訊又是一個字典，這次以每個對等客戶的ID為關鍵字，每個對等客戶在串連到Tracing Service器的時候都會為自己產生一個ID，這個ID怎麼產生的以後看用戶端的代碼可以知道，現在我們知道的是，它的長度必須為20。這個字典的值，嗯，又是個字典，不過這個字典的意義就明顯多啦，包括了IP是多少，連接埠是多少，還剩多少沒有下載完。因此state的內容可以看成是這樣的：{'peers':{},...}，其中peers的結構是這樣的：{hash1:{ID1:{'ip':xxx.xxx.xxx.xxx,'port':xxxx,left:XXXX},ID2:{'ip':yyy.yyy.yyy.yyy,'port':yyyy,left:YYYY},...},hash2:{...},...}。以上是state中'peers'這一項。'completed'這一項就相對結構簡單了，它記錄的是每個種子檔案的下載完成情況，它的結構是個字典，以每個種子的資訊部分的訊息摘要值為關鍵字，而對應的值就是一個整數，表示該種子檔案已經有多少人完成了下載。接下來是'allowed'項，這項記錄了該Tracing Service器所關注的所有的種子的資訊，仍然以資訊部分的訊息摘要值為關鍵字，內容就是該種子檔案的實際資訊，從後面的分析(對BitTorrent/parsedir.py的分析)可以知道是哪些資訊，另外由於之前對種子檔案的內部結構我們已經比較清楚，所以也可以猜出部分。state中還有'allowed_dir_files'項，這一項也是記錄檔案資訊的字典，但它是以每個檔案的檔案名稱為關鍵字(而不是訊息摘要值)，每個檔案的項目是一個列表，結構如下：[(檔案修改時間,檔案大小),訊息摘要值]，就是說，這個以檔案名稱為關鍵字的字典它的每一個值都是一個列表，這個列表有兩個元素，第一個元素是一個二元組，內容是檔案修改時間和檔案大小，第二個元素是訊息摘要值。最後，我們注意到statefiletemplate在處理'allowed'項和'allowed_dir_files'項時還有一些額外的檢查代碼，即所有在'allowed'項裡面出現的元素，它的訊息摘要值都必須在'allowed_dir_files'項中出現，且'allowed_dir_files'中所有的項中的值的訊息摘要部分必須在'allowed'中出現，另外'allowed_dir_files'中不得出現重複的訊息摘要值('allowed'項本身就以訊息摘要值為關鍵字，而字典的關鍵字已經保證不會重複)。
    因此現在我們知道了state中的注意部分的結構。下面我們注意這兩句：
    self.downloads    = self.state.setdefault('peers', {})
    self.completed    = self.state.setdefault('completed', {})
    這樣就把state中的'peers'和'completed'的值傳到了downloads和completed中，更重要的是，以後在Tracing Service器的運行過程中，如果'peers'和'completed'的值發生改變(那簡直是一定的)，state中的相應值也會發生變化，這樣，儲存dfile時，就可以及時更新state的值了。以後我們分析Tracing Service器運行過程的時候少不了和它們打交道，現在我們可以先記住，downloads儲存了所有的下載的用戶端的資訊，completed儲存所有的種子的下載完成情況的統計資訊。
    下面的這個for迴圈根據設定檔處理NAT的問題，以及計算種子的個數。completed只是記錄所有下載完成的客戶的數目，而只有已經下載完成(left=0)，但是還在downloads中出現(即下載完畢但是沒有關閉用戶端)的用戶端才算是一個種子。這裡我們可以很容易得看出，seedcount是一個以資訊摘要為關鍵字，整型為值的統計種子數的一個字典。
    下面是一個計算的變數，times表示了每個種子(以資訊摘要為關鍵字)中每個客戶(以客戶ID為關鍵字)的上次的有活動的時間。接下來增加了兩個任務，每隔一段時間儲存一下dfile，並且檢查下載的用戶端是否已經有很長時間沒有反應的。
    接下來準備一個記錄檔，並試圖把標準輸出重新導向到這個記錄檔中。
    最後要去尋找該Tracing Service器所關注的所有的種子，即parsedir，這個函數可以自己去看，相信在知道了種子檔案的編碼格式和前面的狀態中的項的要求後，不難分析。總得說來，這個函數做了以下事情，即尋找某個目錄下所有的.torrent檔案，把這些檔案中的資訊讀取進來，並且排除錯誤，重複等等不合要求的，然後進行加工，輸出符合要求的結果，儲存在allowed和allowed_dir_files中，進而影響state。
    現在tracker對象已經建立起來，它已經有它要進行跟蹤的所有種子的資訊，並且準備好了維護所有串連進來的客戶的列表，因此它可以正式開始提供Tracing Service了。下一次我們就可以看看tracker動起來的效果。