• <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>

            大龍的博客

            常用鏈接

            統計

            最新評論

            BitTorrent 協議規范(BT協議集合)

            翻譯:小馬哥
            日期:2004-5-22 


            -----------------------------------------------------------------------------------------------------------
            BitTorrent 是一種分發文件的協議。它通過URL來識別內容,并且可以無縫的和web進行交互。它基于HTTP協議,它的優勢是:如果有多個下載者并發的下載同一個文件,那么,每個下載者也同時為其它下載者上傳文件,這樣,文件源可以支持大量的用戶進行下載,而只帶來適當的負載的增長。(譯注:因為大量的負載被均衡到整個系統中,所以提供源文件的機器的負載只有少量增長)

            一個BT文件分布系統由下列實體組成:
            一個普通的web服務器
            一個靜態的“元信息”文件
            一個跟蹤(tracker)服務器
            終端用戶的web瀏覽器
            終端下載者

            理想的情況是多個終端用戶在下載同一個文件。
            要提供文件共享,那么一臺主機需要執行以下步驟:
            Ø運行一個 tracker服務器(或者,已經有一個tracker服務器在運行了也可以)
            Ø運行一個web服務器,例如apache,或者已經有一個web服務器在運行了。
            Ø在web服務器上,將文件擴展名.torrent 和MIME類型 application/x-bittorrent關聯起來(或者已經關聯了)
            Ø根據 tracker服務器的 URL 和要共享的文件來創建一個“元信息”文件(.torrent)。
            Ø將“元信息”文件發布到web服務器上
            Ø在某個web頁面上,添加一個到“元信息”文件的鏈接。
            Ø運行一個已經擁有完整文件的下載者(被成為’origin’,或者’seed’,種子)

            要開始下載文件,那么終端用戶執行以下步驟:
            Ø安裝 BT(或者已經安裝)
            Ø訪問提供 .torrent 文件的web服務器
            Ø點擊到 .torrent 文件的鏈接(譯注:這時候,bt會彈出一個對話框)
            Ø選擇要把下載的文件保存到哪里?或者是一次斷點續傳
            Ø等待下載的完成。
            Ø結束bt程序的運行(如果不主動結束,那么bt會一直為其它人提供文件上傳)

            各個部分之間的連通性如下:
            網站負責提供一個靜態的文件,而把BT輔助程序(客戶端)放在客戶端機器上。
            Trackers從所有下載者處接收信息,并返回給它們一個隨機的peers的列表。這種交互是通過HTTP或HTTPS協議來完成的。
            下載者周期性的向tracker登記,使得tracker能了解它們的進度;下載者之間通過直接連接進行數據的上傳和下載。這種連接使用的是 BitTorrent 對等協議,它基于TCP。
            Origin只負責上傳,從不下載,因為它已經擁有了完整的文件。Origin是必須的。

            元文件和tracker的響應都采用的是一種簡單、有效、可擴展的格式,被稱為bencoding,它可以包含字符串和整數。由于對不需要的字典關鍵字可以忽略,所以這種格式具有可擴展性,其它選項以后可以方便的加進來。

            --------------------------------------------------------------------------------------------------------------------

            Bencoding格式如下:
            對于字符串,首先是一個字符串的長度,然后是冒號,后面跟著實際的字符串,例如:4:spam,就是“ spam”
            整數編碼如下,以 ‘i’ 開始,然后10進制的整數值,最后以’e’結尾。例如,i3e表示3,I-3e表示-3。整數沒有大小限制。I-0e是無效的。除了 i0e外,所以以0起始的整數都無效。I0e當然表示0。
            列表編碼如下,以’l’開始,接下來是列表值的編碼(也采用bencoded編碼),最后以’e’結束。例如:l4:spam4:eggse 表示 [‘spam’, ‘eggs’]。
            字典編碼如下,以’d’開始,接下來是可選的keys和它對應的值,最戶以’e’結束。例如:d3:cow3:moo4:spam4:eggse,表示{‘cow’:’moo’,’spam’:’eggs’},而d4:spaml1:al:bee 表示 {‘spam’:[‘a’,’b’]}。鍵值必須是字符串,而且已經排序(并非是按照字母順序排序,而是根據原始的字符串進行排序)。

            元文件是采用bencoded編碼的字典,包括以下關鍵字:

            announce tracker的服務器

            info 它實際上是一個字典,包括以下關鍵字:

            Name:
            一個字符串,在保存文件的時候,作為一個建議值。僅僅是個建議而已,你可以用別的名字保存文件。
            Piece length:
            為了更好的傳輸,文件被分隔成等長的片斷,除了最后一個片斷以外,這個值就是片斷的大小。片斷大小幾乎一直都是2的冪,最常用的是 256k(BT的前一個版本3.2,用的是1M作為默認大小)
            Pieces:
            一個長度為20的整數倍的字符串。它將再被分隔為20字節長的字符串,每個子串都是相應片斷的hash值。

            此外,還有一個length或files的關鍵字,這兩個關鍵字只能出現一個。如果是length,那么表示要下載的僅僅是單個文件,如果是files那么要下載的是一個目錄中的多個文件。
            如果是單個文件,那么length是該文件的長度。

            為了能支持其它關鍵字,對于多個文件的情況,也把它當作一個文件來看,也就是按照文件出現的順序,把每個文件的信息連接起來,形成一個字符串。每個文件的信息實際上也是一個字典,包括以下關鍵字:
            Length:文件長度
            Path:子目錄名稱的列表,列表最后一項是文件的實際名稱。(不允許出現列表為空的情況)。
            Name:在單文件情況下,name是文件的名稱,而在多文件情況下,name是目錄的名稱。

            Tracker查詢。Trakcer通過HTTP的GET命令的參數來接收信息,而響應給對方(也就是下載者)的是經過bencoded編碼的消息。注意,盡管當前的tracker的實現需要一個web服務器,它實際上可以運行的更輕便一些,例如,作為apache的一個模塊。

            --------------------------------------------------------------------------------------------------------------------------------

            Tracker GET requests have the following keys:

            發送給Tracker的GET請求,包含以下關鍵字:

            Info_hash:
            元文件中info部分的sha hash,20字節長。這個字符創幾乎肯定需要被轉義(譯注:在URL中,有些字符不能出現,必須通過unicode進行編碼)

            Peer_id:
            下載者的id,一個20字節長的字符串。每個下載者在開始一次新的下載之前,需要隨機創建這個id。這個字符串通常也需要被轉義。

            Ip:
            一個可選的參數,給出了peer的ip地址(或者dns名稱?)。通常用在origin身上,如果它和tracker在同一個機器上。

            Port:
            peer所監聽的端口。下載者通常在在 6881 端口上監聽,如果該端口被占用,那么會一直嘗試到 6889,如果都被占用,那么就放棄監聽。

            Uploaded:
            已經上載的數據大小,十進制表示。

            Downloaded:
            已經下載的數據大小,十進制表示

            Left:
            該peer還有多少數據沒有下載完,十進制表示。注意,這個值不能根據文件長度和已下載數據大小計算出來,因為很可能是斷點續傳,如果因為檢查文件完整性失敗而必須重新下載的時候,這也提供了一個機會。

            Event:
            一個可選的關鍵字,值是started、compted或者stopped之一(也可以為空,不做處理)。如果不出現該關鍵字,。在一次下載剛開始的時候,該值被設置為started,在下載完成之后,設置為completed。如果下載者停止了下載,那么該值設置為stopped。

            Tracker的響應是用bencoded編碼的字典。如果tracker的響應中有一個關鍵字failure reason,那么它對應的是一個字符串,用來解釋查詢失敗的原因,其它關鍵字都不再需要了。否則,它必須有兩個關鍵字:Interval:下載者在兩次發送請求之間的時間間隔。Peers:一個字典的列表,每個字典包括以下關鍵字:Peer id,Ip,Port,分別對應peer所選擇的id、ip地址或者dns名稱、端口號。注意,如果某些事件發生,或者需要更多的peers,那么下載者可能不定期的發送請求,

            (downloader 通過 HTTP 的GET 命令來向 tracker 發送查詢請求,tracker 響應一個peers 的列表)

            如果你想對元信息文件或者tracker查詢進行擴展,那么需要同Bram Cohen協調,以確保所有的擴展都是兼容的。

            BT對等協議基于TCP,它很有效率,并不需要設置任何socket選項。(譯注:BT對等協議指的是peer與peer之間交換信息的協議)
            對等的兩個連接是對稱的,消息在兩個方向上同樣的傳遞,數據也可以在任何一個方向上流動。
            一旦某個peer下載完了一個片斷,并且也檢查了它的完整性,那么它就向它所有的peers宣布它擁有了這個片斷。

            --------------------------------------------------------------------------------------------------------------------------------

            連接的任何一端都包含兩比特的狀態信息:是否choked,是否感興趣。Choking是通知對方,沒有數據可以發送,除非unchoking發生。Choking的原因以及技術后文解釋。

            一旦一端狀態變為interested,而另一端變為非choking,那么數據傳輸就開始了。(也就是說,一個peer,如果想從它的某個peer那里得到數據,那么,它首先必須將它兩之間的連接設置為 interested,其實就是發一個消息過去,而另一個peer,要檢查它是否應該給這個家伙發送數據,如果它對這個家伙是 unchoke,那么就可以給它發數據,否則還是不能給它數據)Interested狀態必須一直被設置――任何時候。要用點技巧才能比較好的實現這個目的,但它使得下載者能夠立刻知道哪些peers將開始下載。

            對等協議由一個握手開始,后面是循環的消息流,每個消息的前面,都有一個數字來表示消息的長度。握手的過程首先是先發送19,然后發送“BitTorrent protocol”。19就是“BitTorrent protocol”的長度。
            后續的所有的整數,都采用big-endian 來編碼為4個字節
            在協議名稱之后,是8個保留的字節,這些字節當前都設置為0。
            接下來對元文件中的 info 信息,通過 sha1 計算后得到的 hash值,20個字節長。接收消息方,也會對 info 進行一個 hash 運算,如果這兩個結果不一樣,那么說明對方要的文件,并不是自己所要提供的,所以切斷連接。

            接下來是20個字節的 peer id。
            這就是握手過程

            接下來就是以消息長度開始的消息流,這是可選的。長度為0 的消息,用于保持連接的活動狀態,被忽略。通常每隔2分鐘發送一個這樣的消息。

            其它類型的消息,都有一個字節長的消息類型,可能的值如下:

            ‘choke’, ‘unchoe’, ‘interested’, not interested’類型的消息不再含有其它數據了。

            ‘bitfield’永遠也僅僅是第一個被發送的消息。它的數據實際是一個位圖,如果downloader已經發送了某個片斷,那么對應的位置1,否則置0。Downloaders如果一個片斷也沒有,可以忽略這個消息。(通過這個消息,能知道什么了?)

            ‘have’類型的消息,后面的數據是一個簡單的數字,它是下載者剛剛下載完并檢查過完整性的片斷的索引。(由此,可以看到,peer通過這種消息,很快就相互了解了誰都有什么片斷)

            ‘request’類型的消息,后面包含索引、開始位置和長度)長度是2的冪。當前的實現都用的是215 ,而關閉連接的時候,請求一個超過2 17的長度。(這種類型的消息,就是當一個peer希望另一個peer給它提供片斷的時候,發出的請求)

            ‘cancel’類型的消息,它的數據和’request’消息一樣。它們通常只在下載趨向完成的時候發送,也就是在‘結束模式“階段發送。在一次下載接近完成的時候,最后的幾個片斷需要很長時間才能下載完。為了確保最后幾個片斷盡快下載完,它向所有的peers發送下載請求。為了保證這不帶來可怕的低效,一旦某個片斷下載完成,它就其它peers發送’cancel’消息。(意思就是說,我不要這個片斷了,你要是準備好了,也不用給我發了,可以想象,如果對方還是把數據發送過來了,那么這邊必須忽略這些重復的數據)。

            ---------------------------------------------------------------------------------------------------

            ‘piece’類型的消息,后面保護索引號、開始位置和實際的數據。注意,這種類型的消息和 ‘request’消息之間有潛在的聯系(譯注:因為通常有了request消息之后,才會響應‘piece’消息)。如果choke和unchoke消息發送的過于迅速,或者,傳輸速度變的很慢,那么可能會讀到一些并不是所期望的片斷。( 也就是說,有時候讀到了一些片斷,但這些片斷并不是所想要的)

            posted on 2008-04-25 22:47 大龍 閱讀(1392) 評論(0)  編輯 收藏 引用

            久久国产色AV免费观看| 久久精品一区二区三区不卡| 四虎亚洲国产成人久久精品| 久久久久久久久久久久久久| 九九精品99久久久香蕉| 国内精品久久久久久麻豆| 欧美伊人久久大香线蕉综合| 狠狠狠色丁香婷婷综合久久五月| 久久亚洲国产成人影院网站| 色妞色综合久久夜夜 | 久久精品国产亚洲av麻豆色欲| 久久精品毛片免费观看| 色婷婷久久久SWAG精品| 九九99精品久久久久久| 久久久久高潮综合影院| 久久国产精品免费一区| 国产美女久久精品香蕉69| 久久亚洲中文字幕精品一区| 久久久久国色AV免费观看| 国产精品久久久久影院色| 亚洲精品白浆高清久久久久久| 久久久噜噜噜久久中文字幕色伊伊| 久久无码人妻一区二区三区午夜| 日日狠狠久久偷偷色综合0| 99久久精品毛片免费播放| 伊人久久大香线蕉av一区| 性做久久久久久久久| 久久人人爽人人澡人人高潮AV| 久久久久久久亚洲Av无码| 囯产极品美女高潮无套久久久| 久久久久国产一区二区| 久久精品国产亚洲7777| 亚洲国产成人久久精品影视| 久久国产一区二区| 久久精品国产半推半就| 国产精品青草久久久久婷婷| 久久久久免费看成人影片| 国产亚洲综合久久系列| 成人妇女免费播放久久久| 久久91精品国产91久久小草| 精品久久无码中文字幕|