流基础
两个基本概念，使得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.1和10.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,用于设置用户的头像以及昵称等
这是从XMPP学习——2、登陆的例子 截取的协议传输过程图。
以上内容均参考自wiki百科：xmpp中文翻译计划