電騾協議規范-第一章：概述

1?????? 介紹

1.1 ?????????????????????? 目的和范圍

電騾是基于電驢協議的流行的文件共享程序。本報告描述電騾的網絡行為，并解釋需要理解協議的基本技術。本報告提供一個完整電騾網絡協議規范，包含一個附錄，其中提供信息格式。本文檔中的信息是基于開源的電騾客戶端。下面介紹的目介紹通用的背景，方便讀者理解本文檔，在 [3] 中可以找到其他的電騾信息源。

1.2 ?????????????????????? 概述

電騾網絡是由幾百個電騾服務器和上百萬的電騾客戶端 [1] 組成?？蛻舳藨撨B接到服務器而獲得網絡服務，只要客戶端在系統中，服務器連接一直打開。服務器執行集中式的索引服務（和在 Napster 的一樣），它不會和其他服務器通訊。

每個電騾客戶端預配置一個服務器鏈表和本地文件系統中的共享文件列表?？蛻舳说卿浀骄W絡是使用單一 TCP 連接到電騾服務器，從服務器得到所要的文件和在線的客戶端。同時電騾客戶端和其他客戶端之間有幾百個 TCP 連接來上傳和下載文件。每個電騾客戶端維護一個上載的共享隊列。正在下載的客戶端首先加入到隊列的底部，逐漸的向前，直到到達隊列的定部才開始下載該文件?？蛻舳丝梢詮膸讉€其他的電騾客戶端下載同一個文件，從每個客戶端取不同的分片?？蛻舳艘部梢陨蟼鳑]有完全下載的文件塊；最后，電騾擴展了電驢的能力，允許客戶端交換服務器、其他客戶端和文件的信息。注意客戶和服務器通訊都是基于 TCP 的。

服務器使用一個內部數據庫，數據庫中存儲客戶端和文件的信息。一個電騾服務器并不存儲任何文件，它僅僅扮演文件位置信息的集中索引；另一個功能是作為穿過防火墻的客戶端連接以及不能接受輸入連接的客戶端之間橋梁。橋梁的功能明顯增加了服務器的負載。電騾使用 UDP 來增強客戶端不依賴服務器和客戶端的能力?？蛻舳税l送和接收 UDP 消息的行為對于客戶端日常操作來說不是強制的，并且在防火墻阻止其放松和接受 UDP 消息時有點問題。

1.2.1 ?????????????????????????????????????????? 客戶端到服務器的連接

客戶端啟動的時候使用 TCP 連接到某個電騾服務器，服務器提供一個客戶端 ID 給該客戶端（ 1.3 節），這個 ID 僅僅在客戶端和服務器連接的生命周期內有效（注意，在客戶端有高 ID 是，直到他 IP 地址改變的時候，它才會從所有的服務器受到相同的 ID ）。在客戶端連接建立之后其發送共享的文件給服務器，服務器存儲這些信息到內部數據庫中，數據庫中通常包含幾萬個可用文件或活動的客戶端。電騾的客戶端也將其他想下載的文件列表發送給服務器。第 2 節提供詳細的電騾客戶端和服務器之間 TCP 報文交互的描述。

在連接建立之后，電騾服務器將包含當前客戶端需要下載的文件信息的其他客戶端擁有的文件發送給當前客戶端（這些客戶端叫做源）；從這時開始，電騾客戶端將和其他客戶端之間建立連接， 1.2.2 介紹。

注意， TCP 連接的 C/S 在所有客戶端會話過程中事情打開，在大部分由用戶活動觸發的起初握手事務之后，有時客戶端發送文件查詢請求，其以搜索結果響應，一個搜索事務后面通常是一個到源指定文件的查詢，這個查詢通常返回源（ IP 地址和端口）的列表，請求者可以從他們那里下載請求的文件。

UDP 用來和當前客戶端連接的服務器之外的服務器通訊。 UDP 報文的目的是增強文件查找、源搜索增強和?；睿ūＷC電騾服務器列表中的所有服務器是有效的）。更多的客戶端和服務器之間的報文交互在第 3 章介紹。

1.2.2 ?????????????????????????????????????????? 客戶端到客戶端的連接

電騾的客戶端連接其他客戶端的目的是下載文件；一個文件被分割成小塊。客戶端可以從幾個不同的客戶端下載同一個文件，當然從每一個得到的分片是不一樣的。

兩個客戶端連接好之后，他們交換性能信息，并且協商一個下載（上傳）開始。每個客戶端都有一個下載隊列，這里面保存了正在等待下載文件的客戶端列表。當電騾客戶端的下載隊列是空的時候，一個下載請求可能立即導致一個下載的開始（除非，例如，請求者是被禁止的）。當下載隊列不是空的，一個下載請求的結果是在客戶端請求隊列中添加一個新的記錄；沒有嘗試過在一個給定時間內為每個客戶端提供最小 2.4KB/s 的最小帶寬而同時服務多個客戶端。一個下載客戶端可能被在等待隊列先于他前面的客戶端占先，在下載會話開始的 15 分鐘內，電騾客戶端下載隊列排行被增加來阻止擊潰（ thrashing ）。

當下載客戶端到達下載隊列的開始的時候，上傳客戶端初始化一個連接來將其需要的文件片發送給它。電騾客戶端可能正在幾個其他客戶端的等待隊列中并注冊了下載同一個文件片。當從他們中的一個下載了一個完整的部分時，它不會通知剩下的客戶端來讓他們將自己刪除，它只是將當它自己到達他們等待隊列頭的時候他們發送來的連接拒絕掉。

電騾客戶端使用信用系統（見 1.4 節），目的是鼓勵上傳、并阻止外掛（假裝電騾），電騾使用 RAS 公鑰加密來保護信用系統的安全。

客戶端連接可能使用一些電驢協議中沒有定義的報文，這些報文叫做擴展協議。擴展協議用來實現信用系統、通常的信息交互（例如，更新服務器和源的列表）并且提高發送和接收壓縮的文件分片的性能。

電騾客戶端連接使用 UDP 僅僅在有限情況下，周期性的檢查上傳隊列中對端客戶端的狀態，這些客戶端正在等待下載文件。

1.3 ?????????????????????? 客戶端 ID

客戶端 ID 是在客戶端和服務器之間建立連接握手的時候右服務器分配的 4 個字節標示。一個客戶端 ID 在該服務器和客戶端 TCP 連接的生命周期內有效，雖然萬一客戶端有一個高 ID 直到 IP 地址改變的時候被所有服務器分配同一個 ID ?？蛻舳?/span> ID 分成低 ID 和高 ID 。電騾服務器給那些不能接收輸入連接的客戶端通常分配一個低 ID ；由于低 ID 限制了客戶端使用電騾網絡，并且可能導致服務器拒絕客戶端的連接。一個高 ID 是計算出來了的，基于客戶端的 IP 地址按照下面的方式。本節從電騾協議的觀點來描述客戶端 ID 分配和意義 [3] 。一個高 ID 分配給一個客戶端，其允許客戶端自由的連接電騾他們主機 TCP 端口（默認的是 4662 ）。高 ID 的客戶端使用電騾網絡是沒有限制的。當服務器不能打開到電騾客戶端端口的 TCP 連接時，客戶端將得到一個低 ID 。這通常是該客戶端安裝了一個防火墻其拒絕了輸入連接。一個客戶端在下面情況下可能也會被分配一個低的 ID ：

1．? 當客戶端通過 NAT 和代理服務器連接的時候

2．? 當服務器忙的時候（導致服務器的重連接定時器溢出）。

高 ID 是按照下面的方式來計算的：假定主機 IP 是 X.Y.Z.W ， ID 將是 X+2 ⁸ *Y+2 ¹⁶ *Z+2 ²⁴ *W( 大序表示方式 ) 。低 ID 始終小于 16777216(0X1000000) ，我沒有找到他是如何計算的線索，注意當你有一個低 ID 的時候，不同 SERVER 是不同的。

低 ID 的客戶端沒有公網 IP 地址，其他的客戶端不能直接連接，因此所有的通訊必須通過電騾服務器；這增加了服務器計算負荷，導致服務器不愿意接受低 ID 的客戶端。另外，這表明低 ID 的客戶端不能連接到另外一個低 ID 的客戶端（如果該客戶端不是在同一個服務器上），因為電騾不支持跨服務器的通道。

為了支持低 ID 客戶端，引進一種回調機制，使用這種機制，高 ID 的客戶端可以邀請（通過電騾服務器）低 ID 的客戶端連接到它來交換文件。

1.4 ?????????????????????? 用戶 ID

電騾支持信用系統目的是鼓勵用戶共享文件。用戶上傳的文件越多，信譽值就或高，它在等待隊列中前進的速度就越快。

用戶 ID 是一個 128 位（ 16 字節） GUID ，由串聯的隨機數組成，第 6 和 15 字節不是隨即產生的，他們的值是 14 和 111 。客戶端 ID 僅僅在客戶端和指定服務器會話的過程中是有效的，而用戶 ID （也叫做用戶 hash ）是唯一的且用來表示會話中的客戶端（用戶 ID 表示工作站）。用戶 ID 在信譽系統中扮演重要的角色，這給黑客們假裝其他用戶來得到他們權限提供了動機。電騾支持一種加密模式，其設計為防止欺騙和假裝用戶。這個實現是一個簡單挑戰響應，依賴于 RSA 公鑰 / 私鑰加密。

1.5 ?????????????????????? 文件 ID

文件 ID 用來唯一的標示網絡上的文件以及文件損壞檢查和恢復。注意，電騾并不依賴于文件名稱，目的是唯一標示和索引。一個文件通過全局唯一的 ID 來標示，通過哈希文件的內容來計算。有兩種文件 ID ：第一種主要用來產生唯一文件 ID ，第二中用于損壞檢查和恢復 [3] 。

1.5.1 ?????????????????????????????????????????? 文件哈希

文件通過 128 位 GUID 哈希來唯一標示，通過客戶端和基于文件的內容來計算。 GUID 使用 MD4 算法 [4] 來基于文件的數據計算。當計算文件 ID 時，文件被分成 9.28MB 長的段。一個 GUID 是為每個單獨的段來計算的，然后將所有的哈希合并到一起形成一個唯一的文件 ID 。當一個下載客戶端完全下載一個文件的所有部分時，他計算部分的哈希并和對端發送的哈希部分比較，如果發現那部分損壞，客戶端嘗試從損壞的部分漸進替換位（ 180kb 每次）然后直到哈希計算是正確的為止。

1.5.2 ?????????????????????????????????????????? 根哈希

根哈希使用 SHA1 算法來為每個部分計算，基于 180kb 的塊大小。這提供較高級別的可靠性和錯誤恢復。官方的電騾網站有更詳細的信息。

1.6 ?????????????????????? 電騾協議擴展

盡管電騾完全兼容電驢，它還另外實現幾個擴展，這允許電騾客戶端為他們的用戶提供更好的功能。擴展關注于客戶端和客戶之間的通訊，特別是安全和 UDP 的實現。本文的所有消息流程圖中擴展部分都是灰色的。

1.7 ?????????????????????? 軟硬限制

服務器配置包括良種限制基于活動的用戶數 - 軟和硬。硬限制大于等于軟限制。當活動用戶數量達到軟限制時，服務器停止接受新的低 ID 客戶端連接，當用戶數達到硬限制時，服務器是滿負荷的，不能接受任何客戶端連接了。

posted on 2006-07-23 12:31 笨笨 閱讀(1743) 評論(1)  編輯 收藏 引用 所屬分類: P2P技術