jabber XMPP檔案傳輸的一些情況

1 jabber/xmpp檔案傳輸的一些情況

大家知道，jabber/xmpp是一種 xml流技術，解決的問題主要是即時訊息和出席資訊，xml流技術並不適用於大資料量的傳輸。

即時通訊應用中，訊息和出席資訊的問題相對是比較簡單和容易實現的，xmpp的在這方面的長處在於兩點：

- 使用了xml流技術，xml天然的結構化和可擴充套件性特性，非常適合小資料量的字元資訊交換。

- 更重要的，xmpp是乙個公開的免費的標準，使得不同組織機構的即時訊息可以互通，促使im技術和應用從壟斷走向平民化。

----- 但是即時通訊的同樣也離不開大資料量傳輸，來解決檔案分享，多**應用等問題。為了解決這些問題，xeps中提出了一些辦法。在此之前，我們要區分什麼是大數量傳輸，在xmpp\/xep中，資訊傳輸是所謂字元傳輸，而資料傳輸則是位元組流傳輸(bytestreams)。

xep中對於bytestreams的規定大致如下：

協議

描述

xep-0166: jingle

負責協商和管理所有帶外傳輸的會話

xep-0167: jingle audio via rtp

用rtp傳輸音訊

xep-0176: jingle ice transport

用ice傳輸方法建立和管理資料連線

xep-0177: jingle raw udp transport

純udp傳輸

xep-0180: jingle video via rtp

xep-0181: jingle dtmf

對dtmf的簡單支援

注1：ice還是ietf正在開發的協議，尚未定型。

注2：dtmf也就是雙音訊撥號的**，這裡對dtmf的支援只是從xmpp的角度規定，可以管理類dtmf的會話，這樣可以通過**閘道器在xmpp客戶端和普通**之間用語音聊天。

這些是應用層面的東西，和這裡的話題關係不大，另文再說。現在只說在實際位元組傳輸的處理過程。 jingle的自己傳輸分為三類:

* 傳送方在外網,採用類似oob(xep-0066: out of band data)的方式傳輸.

* 傳送方在內網,採用stun服務傳輸,也就是內網客戶端的埠影射服務,把內網的ip和埠影射到stun的ip和特定埠上，然後把這個外網的ip和埠告訴對方，然後還是採用類似oob(xep-0066: out of band data)的方式傳輸。

* 傳送方在內網，但是沒有可用的stun伺服器，採用relay server來**，也就是這類似於proxy65(xep-0065: socks5 bytestreams)的傳輸方式。

gtalk可以加上執行引數 /log verbose tstamp thread file 在桌面產生乙個詳細的 log 檔案，以下是監聽到的xml

0gtalk client 只有發現對方有 share-v1的情況下才允許檔案傳輸，它似乎不關係 version 的版本.

if you init a file transfer they send:

export.csv

/temporary/7a2e84d3cbf106cb68deed1cc418ca26/

/temporary/de2185dda378483a65e0f8c4ad3e4327/

gtalk 新的檔案傳輸沒有使用已有的jep, 而是利用了 jingle 在連線方面的優勢，google 將會提交乙個新的jep

pseudotcp 現在還沒有相關文件，最早是在picasa的 hello im/photo-sharing程式裡面為增加可靠性而使用，而且現在還沒定型。

下乙個google開源專案libjingle的版本將會看到檔案傳輸的相關**，但這些方法也還沒有定型，將來極有可能會再次變化。