| limumu | 2009-04-29 15:44 | 由于筆者時(shí)間上原因，并沒有仔細(xì)研讀所有的文檔；再者水平有即的原因，可能存在著不正確的描述，敬請(qǐng)指正。
Todo:增加文檔自述
XMPP協(xié)議及其擴(kuò)展
XMPP協(xié)議
Extensible Messaging and Presence Protocol即可擴(kuò)展消息與在線感知協(xié)議，它是一個(gè)基于XML流的即時(shí)通信協(xié)議。由Jabber工作組于1999年開始研發(fā)，2003(有待確認(rèn))被IETF工作組確立為標(biāo)準(zhǔn)的即時(shí)通信協(xié)議。此后又經(jīng)過幾年的發(fā)展與完善，逐漸形成了現(xiàn)在的協(xié)議框架
核心文檔
Extensible Messaging and Presence Protocol (XMPP): Core
這里XMPP協(xié)議框架中最重要的文檔，它定義了XMPP協(xié)議框架下應(yīng)用的網(wǎng)絡(luò)架構(gòu)，這是一個(gè)非常開放的框架，從而使XMPP協(xié)議的極具可擴(kuò)展性、極具開放性。它引入了XML Stream與XML Stanza，并規(guī)定XMPP協(xié)議在通信過程中都使用XML標(biāo)簽。使用XML標(biāo)簽從根本上說是由于協(xié)議開放性與擴(kuò)展性的需要。此外，在通信的安全方面，把TLS安全傳輸機(jī)制與SASL認(rèn)證機(jī)制與引入到內(nèi)核，與XMPP進(jìn)行無縫的連接，為協(xié)議的安全性、可靠性奠定了基礎(chǔ)。
Core文檔還規(guī)定了錯(cuò)誤的定義及處理、XML的使用規(guī)范、JID的定義、命名規(guī)范等等。所以這是所有基于XMPP協(xié)議的應(yīng)用都必需支持的文檔
Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
Core文檔中只對(duì)支持XMPP協(xié)議的應(yīng)用作出了最基本的規(guī)范，并沒有對(duì)消息與在線狀態(tài)進(jìn)行詳細(xì)的定義。從應(yīng)用的角度來講，Core文檔(RFC3920)中定義的是從連接服務(wù)器到用戶上線之前的工作。
本節(jié)中討論的文檔，規(guī)定的是用戶成功登陸到服務(wù)器之后，發(fā)布更新自己的在線、好友管理、發(fā)送即時(shí)聊天消息等等業(yè)務(wù)。所有的這些業(yè)務(wù)都是通過3種基本的XML Stanza來完成的，IQ Stanza, Presence Stanza, Message Stanza。
RFC3921還對(duì)阻塞策略進(jìn)行了定義，定義是多種阻塞方式。
可以說，RFC3921是RFC3920的充分補(bǔ)充。兩個(gè)文檔結(jié)合起來，就形成了一個(gè)基本的IM通信協(xié)議平臺(tái)，在這個(gè)平臺(tái)上可以開發(fā)出各種各樣的應(yīng)用。XMPP把復(fù)雜的具體的應(yīng)用通過擴(kuò)展來規(guī)定
其他文檔
Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)
(Todo增加對(duì)它的說明)
XMPP協(xié)議的擴(kuò)展框架
RFC3920與RFC3921兩個(gè)核心文檔奠定了XMPP協(xié)議框架的基礎(chǔ)，在這個(gè)框架上可以方便的擴(kuò)展出各種各樣的應(yīng)用。如果說核心的文檔規(guī)定的XMPP的骨架的話，那么這些擴(kuò)展就是XMPP應(yīng)用上的肉。
Jabber Software Foundation對(duì)擴(kuò)展進(jìn)行了規(guī)范。如果一個(gè)擴(kuò)展協(xié)議可發(fā)布成為公開的擴(kuò)展應(yīng)用，那么它必需遵循XMPP Extension Protocols。到目前為止，已經(jīng)有很多的應(yīng)用擴(kuò)展，這些擴(kuò)展涉及到實(shí)際IM系統(tǒng)中需的各種需求。
擴(kuò)展協(xié)議的標(biāo)準(zhǔn)化進(jìn)程
Todo:查閱有關(guān)文檔，在此做簡(jiǎn)要說明
根據(jù)筆者目前的了解，主要可分為以下幾個(gè)方面
基礎(chǔ)應(yīng)用擴(kuò)展
[1] XEP-0004 Data Forms
[2] XEP-0030 Service Discovery
[3] XEP-0076 Malicious Stanzas
[4] XEP-0053 XMPP Registrar
[5] XEP-0090 Entity Time
[6] XEP-0092 Software Version
[7] XEP-0114 Jabber Component Protocol
[8] XEP-0115 Entity Capabilities
[9] XEP-0124 HTTP Binding
[10] XEP-0138 Stream Compression
[11] XEP-0154 User Profile
IM應(yīng)用擴(kuò)展
[1] XEP-0045 Multi-User Chat
[2] XEP-0047 In-Band Bytestreams (IBB)
[3] XEP-0049 Private XML Storage
[4] XEP-0055 Jabber Search
[5] XEP-0060 Publish-Subscribe
[6] XEP-0077 In-Band Registration
[7] XEP-0083 Nested Roster Groups
[8] XEP-0084 User Avatar
[9] XEP-0107 User Mood
[10] XEP-0146 Remote Controlling Clients
[11] XEP-0163 Personal Eventing via Pubsub
[12] XEP-0172 User Nickname
P2P擴(kuò)展
[1] XEP-0096 File Transfer
[2] XEP-0003 Proxy Accept Socket Service
[3] XEP-0166 Jingle
[4] XEP-0167 Jingle Audio Content Description Format
[5] XEP-0176 Jingle ICE Transport
[6] XEP-0177 Jingle Raw UDP Transport
[7] XEP-0180 Jingle Video Content Description Format
[8] XEP-0181 Jingle DTMF
[9] XEP-0183 Jingle Telepathy Transport Method
Todo:對(duì)上面列出的文件做簡(jiǎn)單的介紹，如果不是很確定的文件，則特別說明
上面列出的只是筆者工作中涉及到的一些文檔，并實(shí)現(xiàn)了部分的擴(kuò)展協(xié)議。由于工作上原因，有些文檔只是有所了解，而沒有深入研讀。XMPP官方網(wǎng)站上列出了
基于XMPP協(xié)議的產(chǎn)品
現(xiàn)在已經(jīng)有很多基于XMPP協(xié)議開發(fā)的產(chǎn)品，很多公司也選擇她作為即時(shí)通信的協(xié)議。Blogcn公司新開發(fā)的Rabo3.0中即時(shí)通信采用就是XMPP協(xié)議。Google公司推出即時(shí)通信工具，gtalk也采用的是XMPP協(xié)議[參考gtalk]。在開源領(lǐng)域，也已經(jīng)出現(xiàn)了很多開源的工程，即有開源的客戶端也有開源的服務(wù)器。
Jingle擴(kuò)展框架
Jingle是XMPP協(xié)議上的擴(kuò)展協(xié)議，它著手解決在XMPP協(xié)議框架下的點(diǎn)對(duì)點(diǎn)的連接問題，也即P2P連接。在Jingle框架下，即使用戶在防火墻或是NAT網(wǎng)絡(luò)保護(hù)之下，也能夠建立連接，從而提供文件傳送、視頻、音頻服務(wù)等等。
Jingle擴(kuò)展
Jingle擴(kuò)展主要包含以下幾個(gè)文件:
XEP-0166 Jingle
這是Jingle擴(kuò)展框架的綱領(lǐng)文件，這個(gè)擴(kuò)展定義Jingle協(xié)議應(yīng)用的特點(diǎn)、應(yīng)用的場(chǎng)合，也決定了Jingle協(xié)議自身的特點(diǎn)[[viii]]。從作者信息來看，Jingle協(xié)議是由google公司開發(fā)的。它作了如下的規(guī)定：
1) 目標(biāo)是建立點(diǎn)對(duì)點(diǎn)的連接，不管是否在防火墻或是NAT網(wǎng)絡(luò)下
2) 將傳輸與內(nèi)容分離
3) 有關(guān)Jingle會(huì)話的過程
XEP-0167 Jingle Audio Content Description Format
Todo增加描述
XEP-0176 Jingle ICE Transport
在Jingle框架下，它屬于Jingle的傳輸方式。這個(gè)文件解決了如何讓防火墻或是NAT保護(hù)下的實(shí)體建立P2P連接的問題。
從協(xié)議的名字可以看出，它是利用了ICE協(xié)議來建立P2P連接的。ICE協(xié)議是一個(gè)基于STUN協(xié)議的一個(gè)旨在建立實(shí)體間P2P連接的協(xié)議(下文中有專門的說明)。XEP-0176所做的工作就是，將ICE協(xié)議與XMPP協(xié)議結(jié)合起來，也就是用XMPP協(xié)議作為ICE的signal channel，在它的協(xié)調(diào)之下建立連接。
XEP-0177 Jingle Raw UDP Transport
顧名思義，XEP-0177 Jingle Raw UDP Transport是直接建立連接，它也是一種傳輸?shù)姆绞健５桥cXEP-0176 Jingle ICE Transport方式不同，它只能建立沒有防火墻且在同一網(wǎng)絡(luò)下面的P2P連接。
XEP-0180 Jingle Video Content Description Format
Todo增加描述
XEP-0181 Jingle DTMF
XEP-0183 Jingle Telepathy Transport Method
Rabo3.0中采用的文件傳輸協(xié)議
由于到目前為止，Jingle框架下還沒有專門的文件傳送協(xié)議(即內(nèi)容為文件)。所以，Rabo在開發(fā)中，采用的是自定義的基于Jingle框架的文件傳送協(xié)議。這個(gè)協(xié)議的正文請(qǐng)參考《P2P文件、文件夾傳送擴(kuò)展協(xié)議BFT――Blogcned File Transfer 1.0》版本[[xvii]]
Jingle框架的特點(diǎn)
傳輸內(nèi)容與傳輸方式分離
Jingle在設(shè)計(jì)時(shí)，就將傳輸?shù)膬?nèi)容與傳輸?shù)姆绞竭M(jìn)行分離，內(nèi)容可以利用多種傳輸方式進(jìn)行傳輸，內(nèi)容是復(fù)雜多樣的，對(duì)傳輸方式也有著不同的要求。而傳輸方式也有多種，不同的傳輸方式，可以應(yīng)用到不同的場(chǎng)合。
在Jingle中目前有對(duì)Audio、Video進(jìn)行專門的規(guī)定。XEP-0167: Jingle Audio via RTP與XEP-0180 Jingle Video via RTP。由于還沒有專門對(duì)它進(jìn)行研究過，所以這里先不作進(jìn)一步的描述[todo]。
在傳輸方式上，也有很多種，這些在前面介紹Jingle擴(kuò)展的文件時(shí)有提到過。
可擴(kuò)展性
Jingle框架傳承了XMPP協(xié)議的特點(diǎn)，也極具可擴(kuò)展性。這得益于傳輸內(nèi)容與傳輸方式的分離的設(shè)計(jì)理念。
基于Jingle提供的幾種傳輸方式下，我們可以根據(jù)需求設(shè)計(jì)支持不同的傳輸內(nèi)容。比如文件傳送、目錄共享，都可以很方便的添加進(jìn)來。這些擴(kuò)展在gtalk中也得到應(yīng)用。
值得專門提出的是，Rabo3中的采用的文件傳輸協(xié)議也是基于XEP-0176 Jingle ICE Transport專門設(shè)計(jì)的。
可部署性
Jingle擴(kuò)展框架在應(yīng)用時(shí)，非常的方便。在兩個(gè)實(shí)體之間要建立P2P連接時(shí)，只要實(shí)體雙方都支持相應(yīng)的傳輸方式與傳輸內(nèi)容，在理想的情況下，它不需要XMPP服務(wù)器的任務(wù)支持，也不需要其它第三方的中轉(zhuǎn)，就可以建立連接。理想的情況是指，雙方可以直接建立連接的情況下，比如在同一個(gè)局域網(wǎng)或者沒有防火墻保護(hù)。
如果在不理想的情況下，原先的XMPP網(wǎng)絡(luò)框架[2]：
C1----S1---S2---C3 |C2----+--G1===FN1===FC1
只需要作簡(jiǎn)單的擴(kuò)展即可支持Jingle的P2P連接。
由于在不理想的情況下，兩個(gè)實(shí)體之間建立連接需要通過XEP-0176 Jingle ICE Transport協(xié)議來建立。這種傳輸方式是基于ICE&STUN的，所以只需要部署STUN服務(wù)器。如果愿意的話，還可以部署stun relay server[]，這樣就可以支持所有情況下的P2P連接，但是部署stun relay server的代價(jià)是昂貴的[參考stun relay server的部署]。
Jingle與P2P技術(shù)
Jinlge中XEP-0176 Jingle ICE Transport傳輸方式支持在防火墻與NAT網(wǎng)絡(luò)保護(hù)下的P2P連接的。
XEP176本身并沒有探討如何建立P2P連接，它所做的工作就是使用ICE與STUN協(xié)議來建立連接。ICE是一個(gè)標(biāo)準(zhǔn)的建立P2P連接性檢查的協(xié)議，它自身不能獨(dú)立的工作，而需要在信號(hào)通道的協(xié)調(diào)下建立連接。ICE在描述時(shí)，是采用SIP協(xié)議[參考sip協(xié)議]作為它的信道。
XEP176就是將ICE中的信道改用XMPP，在XMPP的協(xié)調(diào)下建立P2P連接。
Blice 1.0
Blice是由Blogcn公司開發(fā)的基于ICE與STUN協(xié)議的庫(kù)，它帶有以下功能：
[1] 實(shí)現(xiàn)STUN協(xié)議，包括了STUN的客戶端與簡(jiǎn)化的服務(wù)端，因此1.能夠發(fā)現(xiàn)自身的映射地址2.發(fā)現(xiàn)STUN請(qǐng)求中的對(duì)方的映射地址
[2] ICE協(xié)議的實(shí)現(xiàn)，是基于STUN協(xié)議的建立連接性檢查應(yīng)用。Blice1.0中基本上實(shí)現(xiàn)了ICE規(guī)范中的大部分內(nèi)容，但并不完全兼容[參考Blice程序設(shè)計(jì)]。
參考文獻(xiàn)
--------------------------------------------------------------------------------
http://www.xmpp.org/about/history.shtml,History of XMPP
[ii]Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” RFC 3920, October 2004
[iii]Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” RFC 3921, October 2004
[iv]XMPP Standards Foundation,XEP-0001 XMPP Extension Protocols, Version: 1.18, 2006-12-07
[v] XMPP Extensions
[vi] Jabber/XMPP server implementations
[vii] Jabber/XMPP clients
[viii] Scott Ludwig, Joe Beda, Peter Saint-Andre,XEP-0166: Jingle, Version: 0.17, 2007-06-20
[ix] Scott Ludwig, Peter Saint-Andre, Sean Egan, Robert McQueen,XEP-0167: Jingle Audio via RTP, Version: 0.9, 2007-04-17
[x] Peter Saint-Andre, Joe Beda, Scott Ludwig, Joe Hildebrand, Sean EganXEP-0176: Jingle ICE Transport, Version: 0.9, 2007-06-28
[xi]Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols <http://tools.ietf.org/html/draft-ietf-mmusic-ice>. Work in progress.
[xii]J. Rosenberg, C. Huitema, R. Mahy, D. Wing,Simple Traversal Underneath Network Address Translators (NAT) (STUN)draft-ietf-behave-rfc3489bis-04,Internet-Draft, October 23, 2006,Expires: April 26, 2007
[xiii] Joe Beda, Peter Saint-Andre, Scott Ludwig, Joe Hildebrand, Sean Egan,XEP-0177: Jingle Raw UDP Transport, Version: 0.7, 2007-06-25
[xiv] Peter Saint-Andre, Milton Chen,XEP-0180: Jingle Video via RTP, Version: 0.8, 2007-05-23
[xv] Peter Saint-Andre, Sean Egan,XEP-0181: Jingle DTMF, Version: 0.6, 2007-06-20
[xvi] Peter Saint-Andre,XEP-0183: Jingle Telepathy Transport, Version: 1.0, 2006-04-01 | |
