torrent檔案內的資料結構分為以下幾部分：效果可以看下具體51搜尋展示結合xunsearch全文檢索技術，可以達到毫秒級的資料搜尋
announce:tracker的主伺服器
announce-list：tracker伺服器列表
comment:種子檔案的注釋
comment.utf-8：種子檔案注釋的utf-8編碼
creation date：種子檔案建立的時間，是從2023年1月1日00:00:00到現在的秒數。
encoding:種子檔案的預設編碼，比如gb2312，big5，utf-8等
當種子裡包含多個檔案時，info欄位包括如下子欄位：
files：表示檔案的名字，大小，該欄位包含如下三個子欄位：
lenghth：檔案的大小，用byte計算
path.utf-8：檔名的utf-8編碼，同上
以上的三個字段每個檔案都有一組值。
name.utf-8:推薦的資料夾名的utf-8編碼，同上。
piece length：每個檔案塊的大小，用byte計算
pieces：檔案的特徵資訊，該欄位比較大，實際上是種子內包含所有的檔案段的sha1的校驗值的連線，即將所有檔案按照piece length的位元組大小分成塊，每塊計算乙個sha1值，然後將這些值連線起來就形成了pieces欄位，由於sha1的校驗值為20byte，所以該字段的大小始終為20的整數倍位元組。該字段是torrent檔案中體積最大的部分，可見如果大檔案分塊很小，會造成torrent檔案體積龐大。
publisher：檔案發布者的名字
publisher.utf-8：檔案發布者的名字的utf-8編碼
另外，當發布單檔案時，files欄位是沒有的，而
lenghth:
name：
name.utf-8:
這三個字段負責描述單檔案的屬性：大小，名字，名字的utf-8編碼。其他專案和多檔案相同。
以上的專案即為info欄位的全部。
說到info就不得不說info_hash，這個值是info欄位的hash值，20個byte，同樣是使用sha1作為hash函式。由於info欄位是發布的檔案資訊構成的，所以info_hash在bt協議中是用來識別不同的種子檔案的。基本上每個種子檔案的info_hash都是不同的(至少現在還沒有人發現有sha的衝突)，所以bt伺服器以及客戶端都是以這個值來識別不同的種子檔案的。
計算的具體範圍是從info欄位開始(不包含"info"這四個位元組)，一直到nodes欄位為止(不包含"nodes"這5個位元組和nodes前邊表示nodes字段長度的"5:"這兩個位元組)。另外，info_hash值是即時計算的，並不包含在torrent檔案中。
nodes:最後的乙個欄位是nodes欄位，這個字段包含一系列ip和相應埠的列表，是用於連線dht初始node。
現在公開乙個DHT網路爬蟲
p2p系統的應用越來越廣泛，在檔案共享 流 服務 即時通訊交流 計算和儲存能力共享以及協同處理與服務等方面都能看到p2p的存在，一些p2p應用如napster emule bittorrent等早已是家喻戶曉了。效果可以看下具體51搜尋展示結合xunsearch全文檢索技術，可以達到毫秒級的資料搜尋...
現在公開乙個DHT網路爬蟲
p2p系統的應用越來越廣泛，在檔案共享 流 服務 即時通訊交流 計算和儲存能力共享以及協同處理與服務等方面都能看到p2p的存在，一些p2p應用如napster emule bittorrent等早已是家喻戶曉了。效果可以看下具體51搜尋展示結合xunsearch全文檢索技術，可以達到毫秒級的資料搜尋...
現在公開乙個DHT網路爬蟲
dhtcrawler最早的版本有很多問題，修復過的最大的乙個問題是關於erlang定時器的，在dht實現中，需要對每個節點每個peer做超時處理，在erlang中的做法直接是針對每個節點註冊了乙個定時器。這不是問題，問題在於定時器資源就像沒有gc的記憶體資源一樣，是會由於程式設計師的 問題而出現資源...