Gnutella的檔案傳輸機制

一旦一個servent收到一個QueryHit訊息，它可能會建立由這個訊息的結果集描述的檔案集中一個檔案的

下載。檔案是在網路外部下載的，例如建立一個源和目標的直接連接以實現檔案傳輸。檔案資料從來不會

在Gnutella網路上傳輸。
檔案下載協議是HTTP。建議使用HTTP1.1(RFC2616)，但是HTTP1.0(RFC1945)也可以使用。完整而詳細的定

義在RFC中。下面只包括最基本的內容。以下例子假設使用HTTP1.1協議。

初始化下載的servent發送一個下面視窗的一個request字串到目標伺服器
   GET /get/<File Index>/<File Name> HTTP/1.1<cr><lf>
   User-Agent: Gnutella<cr><lf>
   Host: 123.123.123.123:6346<cr><lf>
   Connection: Keep-Alive<cr><lf>
   Range: bytes=0-<cr><lf>
   <cr><lf>
其中<File Index>/<File Name>是QueryHit訊息的結果集中的File Index/File Name對。例如如果一個QueryHit訊息的結果集包含下列條目

   File Index: 2468
   File Size: 4356789
   File Name: Foobar.mp3
那麼這個條目定義的檔案的下載請求會被初始化如下
   GET /get/2468/Foobar.mp3 HTTP/1.1<cr><lf>
   User-Agent: Gnutella<cr><lf>
   Host: 123.123.123.123:6346<cr><lf>
   Connection: Keep-Alive<cr><lf>
   Range: bytes=0-<cr><lf>
   <cr><lf>

Servents必鬚根據標準URL/URI編碼規則對GET請求中的檔案名稱進行編碼。Servents必須接受URL編碼的GET請求。因為有些老Servents不支援編碼，Servents應該接受未編碼的請求，如果一個初始請求返回一個404 Not Found 錯誤，servents可能會嘗試發送一個未編碼的請求。
HTTP1.1要求有Host前序，而且指定了你要串連到的地址。通常接收servent並不要求這點，但這是協議所要求的。
HTTP標準定義了User-Agent字串的允許值。servent開發人員不能對這個值做任何假設。"Gnutella"只是用來解釋用的。
接收到這個請求的伺服器返回HTTP1.1頭例如
   HTTP/1.1 200 OK<cr><lf>
   Server: Gnutella<cr><lf>
   Content-type: application/binary<cr><lf>
   Content-length: 4356789<cr><lf>
   <cr><lf>
接下來是檔案資料，應該讀取伺服器的HTTP響應中提供的Content-length定義的字串長度。
注意：Servents應該使用HTTP1.1版本來完成檔案傳輸，但也應該為HTTP1.0提供一些支援。Servents應該可以接收HTTP/1.0請求，而且應該用重新請求HTTP/1.0如果遠端主機不遵從HTTP/1.1標準。
雖然我們強烈推薦有完全的HTTP1.1支援，一些serevents並沒有做到這一點。但必須支援Gnutella的最重要特性，range requests和持續穩固的串連。但一些老servents，也沒有做到這一噗。
Range requests在下面的視窗中
   GET /get/2468/Foobar.mp3 HTTP/1.1<cr><lf>
   User-Agent: Gnutella<cr><lf>
   Host: 123.123.123.123:6346<cr><lf>
   Connection: Keep-Alive<cr><lf>
   Range: bytes=4932766-5066083<cr><lf>
   <cr><lf>
注意Range頭不一定要同時定義開始和結束位置。得到的響應如下
   HTTP/1.1 206 Partial Content<cr><lf>
   Server: Gnutella<cr><lf>
   Content-Type: audio/mpeg<cr><lf>
   Content-Length: 133318<cr><lf>
   Content-Range: bytes 4932766-5066083/5332732<cr><lf>
   <cr><lf>

 Connection頭告訴遠端主機當傳輸完畢時是否應該關掉串連。"Connection: close"意思是當傳完畢時必

須關掉串連。"Connection: Keep-Alive"或者沒有Connection頭意思是應該保持串連。用戶端可能接著會

發出另一個範圍或者另一個檔案的請求。這個請求可能在上一次傳輸完成之前就已被發送。RFC2616的8.1

章節定義了持續串連。
必須忽視sevent無法識別的標題。

sevents不應該試圖一次從同一個源下載多重的檔案。檔案應該被置為一個隊列。
同樣建議使用和理解在HUGE中描述的HTTP擴充。

防火牆後面的servents
在一次初始設定檔案下載的嘗試中，建立一個到Guntella servent的直連並不總是成功的。這個servent可

能在一個防火牆後面，而這個防火牆並不允許到Guntella連接埠的incoming串連。如果無法建立一個直連，

嘗試下載檔案的servent可能會請求讓共用檔案的servent PUSH檔案。servent可以通過把Push請求路由回

發送QueryHit訊息的servent來請求一個檔案PUSH。PUSH請求的目標servent(由PUSH訊息的Servent

Identifier定義)應該，在收到PUSH訊息之後，嘗試建立一個新的TCP/IP串連到請求的servent（由PUSH消

息的IP地址和連接埠域定義）。如果這個無法建立這個直連，可能是因為發送PUSH請求的servent自己也位

於一個防火牆後面。這樣的話，無法用這個文檔描述的方法進行檔案傳輸。

PUSH訊息的用法

如果從一個不支援incoming串連的servent那裡收到了一個QueryHit訊息，這個servent可能會發送一個

PUSH訊息。如果發送QueryHit訊息的servent在防火牆後面，這就有可能發生。當servent收到一個Push消

息，若且唯若servent_Identifier域包含它本身的servent標識符時，它應該對PUSH請求發出響應。PUSH

訊息頭的Message_Id域不應該包含和它相關的QueryHit訊息相同的值，而應該根據Message_Id產生演算法生

成一個新的值。
PUSH訊息通過Servent標識符的值被傳會QueryHit的發起者。這意味者不同的PUSH訊息可以有著同樣的

Servent Identifier。如果頭部的MessageID相同，PUSH訊息應被認為是重複的。因為PUSH訊息不被廣播

，所以重複的訊息應該是非常少的。

把檔案“推送”到下載端
如果可以建立一個防火牆後的servent到發送PUSH訊息的servent的直連，防火牆後的servent應該立即發

送下面的字串
 GIV <File Index>:<Servent Identifier>/<File Name><lf><lf>
<File Index>和<Servent Identifier>分別是收到的PUSH請求裡面的File Index和Servent Identifier值，而<File Name>是本地檔案表中檔案索引號為<File Index>的檔案的名稱。檔案可能是用URL/URI編碼的。收到GIV的servent(想要收取檔案的servent)應該忽略掉File Index和File Name，然後發起對要下載的檔案的請求。發送GIV的servent必須允許用戶端請求任何檔案，而不只是PUSH訊息中指定的那個檔案。GET請求和檔案下載的其他過程和上述描述的方法相同。
Servent Identifier被格式化為十六進位格式，而且是大小寫不相關的，例如
   GIV 36:809BC12168A1852CFF5D7A785833F600/Foo.txt<lf><lf>
   GIV 124:d51dff817f895598ff0065537c09d503/Bar.html<lf><lf>

如果在一個由PUSH發起的檔案傳輸時TCP串連丟失，強烈建議發起TCP串連的servent（提供檔案的servent

）嘗試重新串連。這是很重要的，因為收取檔案的servent可能沒法再向提供檔案的servent發送另一個

PUSH訊息。