XMPP學習——三、XMPP協議學習補充

流基礎

兩個基本概念,使得XMPP實體之間的小的結構化信息有效載荷能快速地進行異步交換:XML流和XML節。這些術語的定義以下。 數據庫

XML流的定義:

XML流是一個容器,用於任何兩個實體經過網絡進行XML元素的交換. XML流的開始明確表達爲一個打開的 "流頭" (即, 一個包含了適當樹形和命名空間聲明的 XML <stream> 標籤), 而這個XML流的結尾明確表達爲一個關閉的XML </stream> 標籤. 在流的生存期間, 發起方實體能夠經過這個流發送不限數量的XML元素, 這些元素或用來協商這個流 (例如, 完成 TLS協商SASL協商) 或用於 XML節. "發起流" 是從發起方實體 (一般是一個客戶端或服務器) 到接收方實體 (一般是一個服務器), 也可視爲對應發起方 "鏈接到" 或 "和......開啓會話" 接收方實體. 發起流容許從發起方實體到接收方實體的單向通信; 爲了讓接收方實體可以向發起方實體發送節, 接收方實體必須(MUST) 協商一個相反的流 ("應答流").

XML節的定義:

XML節是一個XMPP中的基本語義單位. 一個節就是一個第一層元素 (在流的深度=1),它的元素名是 "message", "presence", 或 "iq" ,而它的合格命名空間是 'jabber:client' 或 'jabber:server'. 相比之下, 任何其餘命名空間限定的第一層元素都不是一個XML節 (stream errors, stream features, TLS相關的元素, SASL相關的元素, 等等.), 由'jabber:client' 或 'jabber:server' 命名空間限定的 <message/>, <presence/>, 或 <iq/> 元素但不在第一層 (例如, 包含在一個擴展元素中的 <message/> 元素 ( 作報告用的 8.4 )也不是一個XML節, 不是命名空間 'jabber:client' 或 'jabber:server'限定的 <message/>, <presence/>, 或 <iq/> 元素也不是一個XML節. 一個XML節典型的包含一個或多個必要的子元素 (以及相關的屬性, 元素, 和 XML 字符串數據) 來傳達所需的信息, 子元素能夠(MAY)使用任何XML命名空間 (見 XML‑NAMES 和本協議的 8.4).

有三種節: message, presence, 和 IQ ("Info/Query"的縮寫). 這些節類型提供三種不一樣的通信原語: 一個 "推送" 機制用於已生成的消息, 一個特定的 "發行-訂閱" 機制用於廣播網絡可用性信息, 和一個 "請求-應答" 機制用於更結構化的數據交換 (相似 HTTP . 更多解釋分別位於 8.2.1 , 8.2.2 , 和 8.2.3 . 服務器

 

從本質上講, 一個XML流做爲會話期間發送的XML節的信封, 而另外一個XML流做爲會話期間接收的XML節的信封. 咱們能夠用以下的簡化模型作一個展現.網絡

+--------------------+--------------------+
| INITIAL STREAM     |  RESPONSE STREAM   |
+--------------------+--------------------+
| <stream>           |                    |
|--------------------|--------------------|
|                    | <stream>           |
|--------------------|--------------------|
| <presence>         |                    |
|   <show/>          |                    |
| </presence>        |                    |
|--------------------|--------------------|
| <message to='foo'> |                    |
|   <body/>          |                    |
| </message>         |                    |
|--------------------|--------------------|
| <iq to='bar'       |                    |
|     type='get'>    |                    |
|   <query/>         |                    |
| </iq>              |                    |
|--------------------|--------------------|
|                    | <iq from='bar'     |
|                    |     type='result'> |
|                    |   <query/>         |
|                    | </iq>              |
|--------------------|--------------------|
| [ ... ]            |                    |
|--------------------|--------------------|
|                    | [ ... ]            |
|--------------------|--------------------|
| </stream>          |                    |
|--------------------|--------------------|
|                    | </stream>          |
+--------------------+--------------------+
 

下表總結了根元素<stream/>的屬性。


+----------+--------------------------+-------------------------+
|          |    初始實體 到 接收實體     |    接收實體 到 初始實體    |
+----------+--------------------------+-------------------------+
| to       | 接收實體JID               | 初始實體JID              |
| from     | 初始實體JID               | 接收實體JID              |
| id       | 忽  略                       | 流標識                     |
| xml:lang | 默認語言                     | 默認語言                   |
| version  | XMPP 1.0+ supported      | XMPP 1.0+ supported     |
+----------+--------------------------+-------------------------+
 

一個基本的鏈接:

C: <?xml version='1.0'?>
   <stream:stream from='juliet@im.example.com' to='im.example.com' version='1.0' xml:lang='en' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'> S: <?xml version='1.0'?>
   <stream:stream from='im.example.com' id='++TR84Sm6A3hnt3Q065SnAbbk3Y=' to='juliet@im.example.com' version='1.0' xml:lang='en' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams'> [ ... stream negotiation ... ] C: <message from='juliet@im.example.com/balcony' to='romeo@example.net' xml:lang='en'>
       <body>Art thou not Romeo, and a Montague?</body>
     </message> S: <message from='romeo@example.net/orchard' to='juliet@im.example.com/balcony' xml:lang='en'>
       <body>Neither, fair saint, if either thee dislike.</body>
     </message> C: </stream:stream> S: </stream:stream>
 

消息語義(Message)

<message/>節是一個"推送"機制,這裏一個實體推送信息到另外一個實體, 相似發生在email系統裏的通信同樣. 全部消息節將擁有'to'屬性用來指定該消息指望的接收者 (見8.1.110.3), 除非消息是被一個已鏈接的客戶端賬號的純JID發送的. 接收到一個帶有'to'地址的消息節以後, 服務器應該嘗試路由或遞送它到指望的接收者那裏(見第十章裏和XML節相關的通用路由和遞送規則). 異步

 

聯機狀態語義(Presence)

<presence/>節是一個特定的"廣播"或"發佈-訂閱"機制, 這裏多個實體接收關於他們訂閱的一個實體的信息(在這個案例中, 是網絡可用性信息). 一般, 發佈客戶端應該發送一個不帶有'to'屬性的聯機狀態節, 這種狀況下該客戶端鏈接的那個服務器將廣播那個節給全部已訂閱的實體. 然而, 發佈客戶端也能夠發送一個帶有'to'屬性的聯機狀態節, 這種狀況下該服務器將路由或遞送那個節到指望的接收者. 儘管<presence/>節大部分狀況下是由XMPP客戶端使用, 它也可能被服務器, 附加服務, 以及任何其餘類型呃XMPP實體使用. 參見第十章中和XML節相關的通用路由和遞送規則, 以及XMPP‑IM中聯機狀態應用的特定規則. 學習

 

IQ語義(IQ)

信息查詢(Info/Query),或IQ, 是一個"請求-應答"機制, 相似某些狀況下的超文本傳輸協議HTTP. IQ的語義容許一個實體對另外一個實體作出一個請求, 並接收一個應答. 這個請求和應答的數據內容由schema或其餘限定IQ元素的直接子元素的XML命名空間相關的結構化定義(見8.4)來限定, 發出請求的實體使用'id'屬性來跟蹤交互過程. 因此, IQ交互沿用告終構化數據交換的常見模式,相似 get/result 或 set/result (儘管適當的時候對於某個請求會返回一個error):加密

請求實體                     應答實體
----------                  ----------
    |                            |
    | <iq id='1' type='get'>     |
    |   [ ... payload ... ]      |
    | </iq>                      |
    | -------------------------> |
    |                            |
    | <iq id='1' type='result'>  |
    |   [ ... payload ... ]      |
    | </iq>                      |
    | <------------------------- |
    |                            |
    | <iq id='2' type='set'>     |
    |   [ ... payload ... ]      |
    | </iq>                      |
    | -------------------------> |
    |                            |
    | <iq id='2' type='error'>   |
    |   [ ... condition ... ]    |
    | </iq>                      |
    | <------------------------- |
    |                            |
 

爲強制這些語義, 如下規則適用:

1. 'id'屬性對於IQ節是必需的.
2. 'type'屬性對於IQ節是必需的. 這個值必須是如下之一; 若是不是, 接收者或中間路由器必須返回一個<bad-request/>節錯誤( 8.3.3.1).
  • get -- 該節請求信息, 查詢須要什麼數據以完成更多操做, 等等.
  • set -- 該節爲完成某個操做提供須要的數據, 設置新值, 取代舊值, 等等.
  • result -- 該節是對成功的get或set請求的應答.
  • error -- 該節報告關於處理或遞送一個get或set請求時發生的錯誤(見8.3).
3. 接收到類型爲"get"或"set"的IQ請求的實體必須返回一個類型爲"result"或"error"的IQ應答. 該應答必須保留請求中的'id'屬性(或爲空,若是生成的節沒有包含'id'屬性).
4. 接收到類型爲"result"或"error"節的實體不能(MUST NOT)發送更多的類型爲"result"或"error"的IQ應答來應答; 然而, 請求實體能夠發送另外一個請求(例如, 一個類型爲"set"的IQ對以前在get/result對中查詢到的信息提供特定的信息).
5. 類型爲"get"或"set"的IQ節必須嚴格地包含一個子元素, 它定義特定請求的語義.
6. 類型爲"result"的IQ節必須包含零或一個子元素.
7. 類型爲"error"的IQ節能夠包含相關的"get"或"set"子元素而且必須包含一個<error/>子元素; 詳見 8.3.

XMPP協議的命名空間:

jabber:iq:private   -- 私有數據存儲,用於本地用戶私人設置信息,好比用戶備註等。
jabber:iq:conference  -- 通常會議,用於多個用戶之間的信息共享
jabber:x:encrypted -- 加密的消息,用於發送加密消息
jabber:x:expire  -- 消息終止
jabber:iq:time  -- 客戶端時間
jabber:iq:auth  -- 簡單用戶認證,通常用於服務器之間或者服務器和客戶端之間的認證
jabber:x:roster  -- 內部花名冊
jabber:x:signed  -- 標記的在線狀態
jabber:iq:search -- 用戶數據庫查詢,用於向服務器發送查詢請求
jabber:iq:register -- 註冊請求,用於用戶註冊相關信息
jabber:x:iq:roster -- 花名冊管理
jabber:x:conference -- 會議邀請,用於向參加會議用戶發送開會通知
jabber:x:event  -- 消息事件
vcard-temp  -- 臨時的vCard,用於設置用戶的頭像以及暱稱等spa

 

這是從XMPP學習——二、登錄的例子 截取的協議傳輸過程圖。.net

image

image

 

以上內容均參考自wiki百科:xmpp中文翻譯計劃翻譯

相關文章
相關標籤/搜索