XMPP协议中文参考指南
绪论
概览
XMPP是一个流化XML[XML]元素的协议，用于准实时的交换消息和出席信息。XMPP 的核心功能定义在Extensible Messaging and Presence Protocol (XMPP): Core [XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]. 这些功能-- 主要是XML流, 使用TLS和SASL,以及流的根元素之下的
需求
为了达到本文的目的, 基本的即时消息和出席信息应用的需求定义在[IMP-REQS],它是一个高阶的规定,一个用户必须完成以下用例:
?和其他用户交换消息
?和其他用户交换出席信息
?管理和其他用户之间的订阅和被订阅
?管理联系人列表中的条目(在XMPP 中这被称为"roster")
?屏蔽和特定的其他用户之间的通信（出或入）
这些功能领域的详细定义在[IMP-REQS]中, 感兴趣的用户可以直接阅读原文关于需求方面的内容。
[IMP-REQS]也规定出席信息服务必须从即时消息服务中分离; 例如, 它必须可能用这个协议来提供一个出席信息服务,一个即时消息服务,或同时提供两者. 尽管本文假定实现和部署希望提供统一的即时消息和出席信息服务, 但没有要求一个服务必须同时提供出席信息服务和即时消息服务, 并且协议也提供了把出席信息服务和即时消息服务分离成为独立服务的可能性.
注意: 虽然基于XMPP的即时消息和出席信息符合[IMP-REQS]的要求,但它不是特意为那个协议设计的,因为基础协议是在RFC 2779成文之前通过Jabber开放源代码社区的一个开放的开发过程发展出来的. 也请注意尽管在Jabber社区发展的协议中定义了许多其他方面的功能,但是这些协议不包含在本文之中,因为它们不是[IMP-REQS]所要求的.
术语
本文继承了[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]定义的术语.
大写关键字"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和"OPTIONAL" 在本文中的含义定义在BCP 14, RFC 2119 \[TERMS\].
XML 节的语法
符合'jabber:client'和'jabber:server'名字空间的XML节的基本语义和通用属性已经在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]中定义了. 无论如何, 这些名字空间也定义了yixie其他的子元素, 比如通用属性'type'的值, 对于即时消息和出席信息应用就是特殊的. 因而, 在选择用于这类应用的特定用例之前, 我们在这里需要先描述一下XML节的语法, 用来补充[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]中的讨论.
消息语法
符合'jabber:client' or 'jabber:server'名字空间的消息节用于"推" 信息到另一个实体.
在即时消息应用中通常的用法是包含，一个单独的消息,在一个聊天会话中的消息，一个多用户聊天室的上下文中的消息，标题或其他警告和错误的消息,
消息的类型
一个消息节的'type' 属性是建议的(RECOMMENDED); 如果包含了它,它指明这个消息的会话上下文,从而提供一个关于表达的线索(例如, 在一个GUI中). 如果包含了它, 'type' 属性必须(MUST)是以下的值之一 :
?chat -- 消息是在一对一聊天会话的语境被发送. 一个兼容的客户端应该
(SHOULD)在一个允许两个实体进行一对一聊天的界面中显示消息,包括适当
的会话历史.
?error -- 发生了一个和上次发送者发送的消息有关的错误(关于节错误语法的详细信息, 参考[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]).
一个兼容客户端应该(SHOULD)在一个适当的界面展示它以通知发送者这个
错误的种类.
?groupchat -- 消息是在一个多用户聊天环境的语境下发送的(类似\[IRC\]). 一个兼容客户端应该(SHOULD)在允许多对多聊天的界面显示这个消息,包括, 包
括这个聊天室的名册和适当的会话历史. 基于XMPP的群聊协议的完整定义
超出了本文的范围.
?headline -- 一个消息可能是由一个递送或广播内容的自动化服务生成的(新闻, 体育, 市场信息, RSS feeds, 等等.). 这个消息是不需要回复的, 一个兼容客
户端应该(SHOULD) 在一个适当的和单独消息,聊天会话,或群聊会话不同的
界面显示这个消息(例如, 不给接收者提供回复能力).
normal -- 这个消息是一个在一对一会话或群聊会话之外的单独消息, 并且它希望接收者能够回复.一个兼容客户端应该(SHOULD)在一个允许接收者回复
的界面显示这个消息, 但不需要会话历史.
一个IM 应用应该(SHOULD)支持所有前述的消息类型;如果一个应用接收了一个没有'type'属性的消息或这个应用不理解'type'属性的值, 它必须(MUST)认为这个消息是一个"normal" 类型(如,"normal" 是缺省的). "error"类型必须(MUST)仅仅在应答一个和从别的实体接收到的消息有关的错误时生成.
尽管'type'属性是可选的(OPTIONAL), 处于礼貌原因对于消息的任何回复总是和原来的消息同一类型;此外, 一些特殊的应用(例如, 一个多用户聊天服务) 可以(MAY)根据它们的判断强制特定消息类型的使用(例如, type='groupchat').
子元素
正如扩展名字空间extended namespaces(第二章第四节)所述, 一个消息节可以(MAY)包含任何适当名字空间的子元素.
和缺省名字空间声明一致, 缺省消息节的名字空间是'jabber:client' 或'jabber:server', 定义了某几个允许的消息节的子元素. 如果消息节的类型是"error", 它必须(MUST)包含一个
1.
2.
3.
主题
主体
但是仅在每个实例的拥有的'xml:lang'属性的值互不相同的时候才可以.
线索
出席信息语法
符合'jabber:client' 或'jabber:server'名字空间的出席信息节用于表达一个实体当前的网络可用性(离线或在线, 包括之后的各种亚状态和可选的用户名义的描述性文本), 并且通知其他实体它的可用性. 出席信息节也用于协商和管理对于其他实体的出席信息的订阅.
出席信息的类型
出席信息节的'type'属性是可选的(OPTIONAL). 一个不拥有任何'type'属性的出席信息节用来通知服务器发送者已经在线并且可以进行通信了, 'type' 属性表示缺乏可用性, 请求管理对其他实体的出席信息的订阅, 请求其他实体的当前出席信息, 或发生了和上次发出的出席信息节有关的错误. 如果包含了它, 'type'属性必须(MUST)拥有以下值之一:
?unavailable -- 通知实体将不可通信.
?subscribe -- 发送者希望订阅接收者的出席信息.
?subscribed -- 发送者允许接收者接收他们的出席信息.
?unsubscribe -- 发送者取消订阅另一个实体的出席信息.
?unsubscribed -- 订阅者的请求被拒绝或以前的订阅被取消.
?probe -- 对一个实体当前的出席信息的请求; 只应(SHOULD)由服务器代替一个用户生成.
?error -- 处理或递送之前发送的出席信息节的时候发生了错误.
关于出席信息语义学的详细信息和基于XMPP的即时消息和出席信息应用程序的订阅模式,参考交换出席信息Exchanging Presence Information(第五章) 和管理订阅Managing Subscriptions(第六章).
子元素
如扩展名字空间extended namespaces(第二章第四节)所述, 一个出席信息节可以(MAY)包含任何适当名字空间的子元素.
和缺省名字空间声明一致, 缺省出席信息节的名字空间是'jabber:client' 或'jabber:server', 定义了某几个允许的出席信息节的子元素. 如果出席信息节的类型是"error", 它必须(MUST)包含一个
1.
2.
3.
展示
可选的(OPTIONAL)
?away -- 实体或资源临时离开.
?chat -- 实体或资源在聊天中是激活的.
?dnd -- 实体或资源是忙(dnd = "不要打扰").
?xa -- 实体或资源是长时间的离开(xa = "长时间离开").
如果没有提供
状态
可选的(OPTIONAL)
优先权
可选的(OPTIONAL)
IQ语法
IQ节提供一个结构化的请求-应答机制. 这个机制的基本语义学(例如, 'id'属性是必需的(REQUIRED))定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920], 然而完成特定用例所需要的特定语义的所有案例定义在扩展名字空间extended namespace(第二章第四节)之中(注意'jabber:client'和'jabber:server'名字空间没有定义除通用的
扩展名字空间
因为在"jabber:client"或"jabber:server"名字空间中定义的三个XML节类型(也包括它们的属性和子元素)提供了一个基本功能级用于消息和出席信息, XMPP使用XML名字空间来扩展节用于提供额外的功能, 所以一个消息或出席信息节可以(MAY)包含一个或更多可选的子元素表达扩展消息含义的内容(例如, 一个XHTML格式版本的消息主体), 并且一个IQ节可以(MAY)包含一个这样的子元素. 这个子元素可以(MAY)有任何名字并且可以(MUST)拥有一个'xmlns'名字空间声明(不同于"jabber:client", "jabber:server", 或"https://www.doczj.com/doc/9414533608.html,/streams")定义所有包含在子元素中的数据.
对于任何特定的扩展名字空间的支持在任何实现中的一部分是可选的(OPTIONAL)(除了在这里定义的扩展名字空间以外). 如果一个实体不理解这样一个名字空间, 实体被期望的行为依赖于这个实体是(1) 接收者或(2) 一个正在路由到接收者的实体
接收者: 如果一个接收者接收了一个包含不理解的子元素的节, 它应该(SHOULD)忽略那个特定的XML数据,例如, 它应该(SHOULD)不处理它或不向用户或相关的应用程序(如果有的话)显示它. 具体来说:
?如果一个实体接收了一个消息或出席信息节包含一个不理解的名字空间, 在节的未知名字空间的这部分应该(SHOULD)被忽略.
?如果一个实体接收了一个消息节中仅有的一个子元素是不理解的, 它必须(MUST)忽略整个节.
?如果一个实体接收了一个类型"get"或"set"的IQ节包含一个不理解的子元素, 这个实体应该(SHOULD)返回一个类型为"error"的
条件的IQ节.
路由: 如果一个路由实体(通常是一个服务器)处理一个包含它不理解的子元素的节, 它应该(SHOULD)原封不动地把它转给接收者而忽略相关的XML数据.
会话的建立
绝大部分基于XMPP的消息和出席信息应用是由一个客户端-服务器体系结构实现的,为了参加期望的即时消息和出席信息活动,需要客户端在服务器上建立一个会话. 无论如何, 在客户端能够建立一个即时消息和出席信息会话之前有很多前提必须(MUST)满足. 它们是:
1.流验证-- 客户端在尝试建立一个会话或发送任何XML节之前必须(MUST)完
成[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]中定义的流验
证.
2.资源绑定-- 完成流验证之后, 一个客户端必须(MUST)绑定一个资源到流上,
使得客户端的地址符合
[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]规定的术语来说
就是一个已连接的资源"connected resource".
如果一个服务器支持会话, 在完成一个[XMPP-CORE|XMPP文档列表/XMPP正式RFC 标准/RFC3920]定义的流验证之后它必须(MUST)在它向客户端声明的流特性中包含一个符合'urn:ietf:params:xml:ns:xmpp-session'名字空间的
服务器向客户端声明会话确定特性:
xmlns='jabber:client' xmlns:stream='https://www.doczj.com/doc/9414533608.html,/streams' id='c2s_345' from='https://www.doczj.com/doc/9414533608.html,' version='1.0'> 收到需要会话确立的通知之后(并且是在完成资源绑定之后), 客户端如果想使用即时消息和出席信息功能必须(MUST)建立一个会话; 它向服务器发送一个符合'urn:ietf:params:xml:ns:xmpp-session'名字空间的类型为"set"并包含空的 步骤1: 客户端向服务器请求会话: type='set' id='sess_1'> 步骤2: 服务器通知客户端会话已经建立: type='result' id='sess_1'/> 建立会话之后, 一个已连接的资源([XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]术语)就被称为一个激活的资源"active resource". 许多错误条件是可能的. 例如, 服务器可能遭遇一个内部条件阻碍了它建立会话, 用户名或授权身份可能缺乏建立会话的许可, 或同一个名字相关的这个资源ID已经有一个激活的资源. 如果服务器遭到一个内部条件阻碍了它建立会话, 它必须(MUST)返回一个错误. 步骤 2 (替代): 服务器应答一个错误(内部服务器错误): xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> 如果用户名或资源不被允许建立一个会话, 服务器必须(MUST)返回一个错误(例如, 被禁止). 步骤 2 (替代): 服务器应答错误(用户名或资源不被允许建立一个会话): xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> 如果已经同一名字已经存在一个激活的资源,服务器必须(MUST) (1) 终止这个激活的资源并允许新请求的会话, 或者(2) 不允许新申请的会话并继续激活的资源. 服务器做哪一步取决于具体的实现, 尽管建议的(RECOMMENDED)实现情景#1. 在情景#1, 服务器应该(SHOULD)发送一个 这个激活的资源的XML流和相关的TCP连接, 并返回一个类型为"result" 的IQ节(表示成功)给新申请的会话. 在情景#2, 服务器应该(SHOULD)发送一个 步骤 2 (替代): 服务器通知现有的激活的资源资源冲突(情景#1): 步骤 2 (替代): 服务器通知新申请的的会话资源冲突(情景#2): 建立一个会话之后, 客户端应该(SHOULD)按以下描述来发送初始化出席信息并请求它的名册, 尽管这些动作是可选的(OPTIONAL). 注意: 在允许建立即时消息和出席信息会话之前, 一个服务器可能(MAY)需要先提供帐号. 可能的提供帐号的方法包括由服务器管理员新建帐号以及使用'jabber:iq:register'名字空间进行带内帐号注册; 后一个方法超出了本文的范围, 但是记录在\[JEP-0077\]（译者注：这个协议已改名为XEP-0077）, 由Jabber Software Foundation \[JSF\]发行（译者注：这个组织也已改名为XSF）. 交换消息 交换消息是XMPP的一个基本用途并且随之而来的是一个用户生成一个发给另一个实体的消息节. 正如用于处理XML节的服务器规则Server Rules for Handling XML Stanzas(第十一章)中所定义的, 发送者的服务器负责递送消息给预定的接收者(如果接收者在同一个服务器上)或路由消息给接收者的服务器(如果接收者在不同的服务器上). 关于消息节的语法和它们已定义的属性和子元素信息, 参考消息语法Message Syntax(第二章第一节). 指明一个预定的接收者 一个即时消息客户端应该(SHOULD)通过提供一个JID或 指定一个消息类型 大家知道, 对于一个消息节来说拥有'type'属性(它的值代表了消息的会话上下文(参见Type(第二章第一节第一小节)))是建议的(RECOMMENDED). 以下例子展示一个'type'属性的合法值: 例子: 一个已定义类型的消息: to='romeo@https://www.doczj.com/doc/9414533608.html,' from='juliet@https://www.doczj.com/doc/9414533608.html,/balcony' type='chat' xml:lang='en'> 指定一个消息主体 一个消息节可以(MAY)(并且经常会)包含一个 例子: 一个带主体的消息: to='romeo@https://www.doczj.com/doc/9414533608.html,' from='juliet@https://www.doczj.com/doc/9414533608.html,/balcony' type='chat' xml:lang='en'> 指定一个消息主题 一个消息节可以(MAY)包含一个或多个 例子: 一个带主题的消息: to='romeo@https://www.doczj.com/doc/9414533608.html,' from='juliet@https://www.doczj.com/doc/9414533608.html,/balcony' type='chat' xml:lang='en'> xml:lang='cz'>Úpěnlivě prosim! 指定一个会话线索 一个消息可以(MAY)包含一个 例子: 一个带线索的会话: to='romeo@https://www.doczj.com/doc/9414533608.html,/orchard' from='juliet@https://www.doczj.com/doc/9414533608.html,/balcony' type='chat' xml:lang='en'> to='juliet@https://www.doczj.com/doc/9414533608.html,/balcony' from='romeo@https://www.doczj.com/doc/9414533608.html,/orchard' type='chat' xml:lang='en'> to='romeo@https://www.doczj.com/doc/9414533608.html,/orchard' from='juliet@https://www.doczj.com/doc/9414533608.html,/balcony' type='chat' xml:lang='en'> 交换出席信息 交换出席信息通过使用出席信息节直接和XMPP相关. 无论如何, 我们看到在这里和消息处理形成一个对比:尽管一个客户端可以(MAY)通过包含一个'to'地址直接给另一个实体发送出席信息, 通常出席信息通知(例如,不包含'type'的或类型为"unavailable"的并且没有'to'地址的出席信息节) 被客户端发送给它的服务器然后由服务器广播给任何订阅了发送实体的出席信息的实体(在RFC 2778 \[IMP-MODEL\]术语中, 这些实体称为订阅者). 这个广播模式不适用于和订阅相关的节或类型为 "error"的出席信息, 而仅适用于以上定义的出席信息通知. (注意: 虽然出席信息可以(MAY)由一个自动化服务代替用户提供, 通常它还是由用户的客户端提供.) 关于出席信息节的语法以及它们的已定义的属性和子元素的信息, 参考[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]. 客户端和服务器出席信息职责 初始化出席信息 建立起一个会话之后, 一个客户端应该(SHOULD)发送初始化出席信息给服务器来通知它的通信可用性.如这里定义的, 初始化出席信息节(1) 必须(MUST) 不拥有'to'地址(这表示它是由服务器代替客户端发送的广播) 并且(2) 必须(MUST) 不拥有'type'属性(者表示拥护的可用性). 在发送初始化出席信息之后, 一个激活的资源被称为可用的资源"available resource". 从一个客户端接收到初始化出席信息之后, 如果这个用户没有一个或更多的已存在的可用资源(如果这个用户已经有一个或更多可用的资源, 服务器明显不需要发送出席信息探测, 因为它已经拥有需要的信息),用户的服务器必须(MUST)做以下的步骤: 1.从用户的全JID(例如, 'type'属性值为'probe'的出席信息节)给已被这个用户订阅了的所有联系人以 确定它们是否可用; 这些联系人就是那些显示在用户的名册中的JID并且 'subscription'属性值为"to"或"both"(注意: 用户的服务器不能(MUST NOT)发 送出席信息探针给用户已经屏蔽入站出席信息通知的联系人, 具体的描述 在屏蔽入站出席信息通知Blocking Inbound Presence Notifications(第十章第 十节).) 2.从用户的全JID (e.g., 有订阅了该用户的出席信息的联系人; 这些联系人就是那些显示在用户的 名册中的JID并且'subscription'属性值为"from"或"both"(注意: 用户的服务器 不能(MUST NOT)发送出席信息探针给用户已经屏蔽出站出席信息通知的联 系人, 具体的描述在屏蔽出站出席信息通知Blocking Outbound Presence Notifications(第十章第十一节).) 另外, 用户的服务器必须(MUST)从用户的新的可用的资源向用户任何现存的可用的资源(如果有的话)广播初始化出席信息. 从用户接收到初始化出席信息之后, 联系人的服务器必须(MUST)递送这个用户的出席信息节给所有联系人的可用资源相应的全JID( 如果用户的服务器接收到一个类型为"error"的出席信息节,而这个节是用来回复服务器代替用户向联系人发送的初始化出席信息, 它不应该(SHOULD NOT)发送更多的出席信息更新给那个联系人(直到并且除非它从这个联系人接收到一个出席信息节). 发送初始化出席信息之后, 用户可以(MAY)在任何时候更新它的出席信息,方法是在会话期间发送一个没有'to'地址也没有'type'属性的出席信息节或'type'属性值为"unavailable"的出席信息节.(注意:一个用户的客户端不应该(SHOULD NOT)发送一个出席信息更新来自行广播用户出席信息和可用性的改变信息.) 如果出席信息节缺乏'type'属性(例如, 表达可用性), 用户的服务器必须(MUST)广播 那个出席信息节的全XML给所有联系人(满足以下三点) (1) 它们在用户的联系人名册中并且订阅类型是"from"或"both", (2) 用户对于这些联系人没有屏蔽出站出席信息通知, 并且(3) 服务器在用户的会话期间没有从它们那里接收到出席信息错误(同样适用于这个用户的其他可用的资源). 如果出席信息节的'type'属性值是"unavailable", 用户的服务器必须(MUST)广播那个出席信息节的全XML给所有符合以上描述的实体, 也适用于用户曾经在会话过程中直接发送了可用出席信息的任何实体(如果用户还没来得及直接发送不可用出席信息给那个实体). 出席信息调查 从用户接收到一个出席信息调查之后, 联系人的服务器应该(SHOULD)应答如下: 1.如果用户联系人的名册中的状态不是"From", "From + Pending Out", 或 "Both" (定义在订阅状态Subscription States(第九章)), 联系人的服务器必须 (MUST)返回一个类型为"error"的出席信息节应答这个出席信息调查(无论 如何, 如果一个服务器从这个服务器的主机名的子域或其他信任的服务接 收到一个出席信息调查, 它可以(MAY)提供这个用户的出席信息给那个实体). 具体来说: 1.如果用户在联系人的名册中的订阅状态是"None", "None + Pending Out", 或"To" (或根本不在联系人的名册中), 联系人的服务器必须 (MUST)返回一个 2.如果用户在联系人的名册中的订阅状态是"None + Pending In", "None + Pending Out/In", 或"To + Pending In", 联系人的服务器必须 (MUST)返回一个 2.其次, 如果联系人对这个用户的纯JID或全JID屏蔽了出席信息通知(使用缺省 列表或激活列表,定义在屏蔽出站出席信息通知Blocking Outbound Presence Notifications (第十章第十一节)), 服务器不能(MUST NOT)应答这个出席信息 调查. 3.然后, 如果联系人没有可用的资源, 服务器必须(MUST) 要么(1) 应答这个出 席信息调查, 向这个用户发送服务器从联系人接收到的最后的类型为 "unavailable"的出席信息节的全XML, 或(2) 不应答. 4.最后, 如果联系人至少有一个可用的资源, 服务器必须(MUST)应答这个出席信 息调查, 向这个用户发送服务器从联系人的每一个可用的资源收到的最后 的没有'to'属性的出席信息节的全XML (再一次的,对于每一个会话都要强制 服从隐私列表). 一个用户可以(MAY)直接发送出席信息给另一个实体(例如, 一个出席信息节,包含'to'属性并且值为另一个实体的JID并且没有'type'属性或'type'属性值为"unavailable"). 可能出现三种情形: 1.如果用户在已经发送过初始化出席信息广播之后,发送不可用信息广播之前,直 接发送出席信息给它的名册中一个订阅状态为"from" 或"both"的联系人, 这个用户的服务器必须(MUST)路由或递送这个出席信息节的全XML(服从隐 私列表)但是不应该(SHOULD NOT) 根据出席信息广播修改联系人的状态(例 如, 它应该(SHOULD)在任何接下来的由用户初始化的出席信息广播包含这 个联系人的JID). 2.如果用户在已经发送过初始化出席信息广播之后,发送不可用信息广播之前,直 接发送出席信息给一个不在用户名册中的实体并且其订阅状态为"from" 或 "both", 这个用户的服务器必须(MUST)路由或递送这个出席信息节的全 XML(服从隐私列表)但是不能(MUST NOT) 根据可用性的出席信息广播来修 改这个联系人的状态(例如, 它不能(MUST NOT)在任何接下来的由用户初始 化的可用性的出席信息广播中包含这个联系人的JID); 无论如何, 如果无法 从用户的可用的资源直接发送出席信息, 用户的服务器必须( MUST)广播不 可用出席信息给那个实体(如果这个用户还没有直接发送不可用出席信息给 那个实体). 3.如果用户不是在已经发送过初始化出席信息广播之后,或在发送不可用信息广 播之前,直接发送出席信息(例如, 资源激活了但是还不可用), 用户的服务器 必须(MUST)认为用户向其直接发送出席信息的这个实体视为上述第二种情 形中的那个实体,采用相同的处理方式. 不可用出席信息 在和一个服务器结束它的会话之前, 客户端应该(SHOULD)雅致地成为不可用的,发送一个最后的没有'to'属性并且'type'属性值为"unavailable"的出席信息节(可选的, 最后的出席信息节可以(MAY)包含一个或多个 无论如何, 用户的服务器不能(MUST NOT)依赖于从一个可用的资源接收最后的出席信息, 因为资源可能意外的变成不可用或可能被服务器判定超时. 如果用户的资源之一因为任何原因成为不可用的(包括雅致的或粗鲁的), 用户的服务器必须(MUST)广播不可用出席信息给所有如下的联系人(1) 在用户的名册中并且订阅类型为"from" 或"both", (2) 用户没有对它们屏蔽出站出席信息的联系人, 以及(3) 用户会话期间,服务器没有从它们那里收到出席信息错误的联系人; 用户的服务器也必须(MUST)发送不可用出席信息节给这个用户的任何其他可用的资源, 以及任何用户的资源曾经在会话期间直接向其发送过出席信息的实体(如果用户还没有直接发送不可用出席信息给那个实体). 在直接发送或广播不可用出席信息之后发送的任何没有'type'属性也没有'to'属性的出席信息节必须(MUST)由服务器广播给所有订阅者. 一个订阅请求就是一个'type'属性值为"subscribe"的出席信息节. 如果订阅请求被发送给一个即时消息联系人, 在'to'属性中提供的JID的格式应该(SHOULD)是 一个用户的服务器不能(MUST NOT)代替用户自动批准订阅请求. 所有订阅申请必须(MUST)直接发给用户的客户端, 具体来说就是这一用户的一个或多个可用的资源. 如果当订阅申请被用户的服务器接收到的时候没有这个用户的可用资源, 用户的服务器必须(MUST)保持这个订阅申请的记录并且在用户下次建立一个可用的资源时递送这个订阅申请, 直到这个用户批准或拒绝这个请求. 如果如果当订阅申请被用户的服务器接收到的时候这个用户有多于一个的可用资源, 用户的服务器必须(MUST)广播这个订阅申请给所有可用的资源(根据处理XML节的服务器规则Server Rules for Handling XML Stanzas(第十一章)). (注意: 如果一个激活的资源还没有提供初始化出席信息, 服务器不能(MUST NOT)认为它是可用的并且因而不能(MUST NOT)发送订阅申请给它.) 无论如何, 如果用户从一个它已授权可以看到用户的出席信息的联系人那里收到一个类型为"subscribe"的出席信息节(例如, 当一个联系人重新同步订阅状态的时候),用户的服务器应该(SHOULD)代替用户自动应答. 另外, 用户的服务器可以(MAY)基于一个特定实现的法则(例如, 无论何时当用户的一个新的资源可用的时候, 或在一段特定长度的时间过去之后)选择重新发送一个未批准的未决订阅申请给这个联系人; 这有助于恢复可能和原始订阅申请有关的瞬间的,无声的错误. 指明可用性状态 一个客户端可以(MAY)使用 例子: 可用性状态: 指明详细的可用性状态信息 通过联合 例子: 详细的状态信息: 指明出席信息优先级 客户端可以(MAY)使用 例子: 出席信息优先级: 出席信息例子 本章的例子用于阐明上述和出席信息相关的协议. 用户是romeo@https://www.doczj.com/doc/9414533608.html,, 他有一个可用的资源, 资源ID为"orchard", 并且他的名册中有以下这些人: ?juliet@https://www.doczj.com/doc/9414533608.html, (subscription="both" 并且她有两个可用的资源, 一个资源名为"chamber" 而另一个资源名为"balcony") ?benvolio@https://www.doczj.com/doc/9414533608.html, (subscription="to") ?mercutio@https://www.doczj.com/doc/9414533608.html, (subscription="from") 例子1: 用户发送初始化出席信息: 例子2: 用户的服务器代替用户发送出席信息调查给subscription="to" 和subscription="both" 的联系人的可用资源: type='probe' from='romeo@https://www.doczj.com/doc/9414533608.html,/orchard' to='juliet@https://www.doczj.com/doc/9414533608.html,'/> type='probe' from='romeo@https://www.doczj.com/doc/9414533608.html,/orchard' to='benvolio@https://www.doczj.com/doc/9414533608.html,'/> 例子3: 用户的服务器代替用户发送初始化出席信息给subscription="from" 和subscription="both"的联系人的可用资源: from='romeo@https://www.doczj.com/doc/9414533608.html,/orchard' to='juliet@https://www.doczj.com/doc/9414533608.html,'/> from='romeo@https://www.doczj.com/doc/9414533608.html,/orchard' to='mercutio@https://www.doczj.com/doc/9414533608.html,'/> 例子4: 联系人的服务器代替所有可用的资源应答出席信息调查: from='juliet@https://www.doczj.com/doc/9414533608.html,/balcony' to='romeo@https://www.doczj.com/doc/9414533608.html,/orchard' xml:lang='en'> from='juliet@https://www.doczj.com/doc/9414533608.html,/chamber' to='romeo@https://www.doczj.com/doc/9414533608.html,/orchard'> from='benvolio@https://www.doczj.com/doc/9414533608.html,/pda' to='romeo@https://www.doczj.com/doc/9414533608.html,/orchard' xml:lang='en'> 例子5: 联系人的服务器递送用户的初始化出席信息给所有可用的资源或返回错误给用户: from='romeo@https://www.doczj.com/doc/9414533608.html,/orchard' to='juliet@https://www.doczj.com/doc/9414533608.html,/chamber'/> from='romeo@https://www.doczj.com/doc/9414533608.html,/orchard' to='juliet@https://www.doczj.com/doc/9414533608.html,/balcony'/> type='error' from='mercutio@https://www.doczj.com/doc/9414533608.html,' to='romeo@https://www.doczj.com/doc/9414533608.html,/orchard'> 例子6: 用户直接发送出席信息给另一个不在他的名册中的用户: from='romeo@https://www.doczj.com/doc/9414533608.html,/orchard' to='nurse@https://www.doczj.com/doc/9414533608.html,' xml:lang='en'> 例子7: 用户发送更新的可用出席信息用于广播: 例子8: 用户的服务器仅向一个联系人广播更新的出席信息(不是那些返回错误的联系人,也不是那些用户直接向其发送出席信息的联系人): from='romeo@https://www.doczj.com/doc/9414533608.html,/orchard' to='juliet@https://www.doczj.com/doc/9414533608.html,' xml:lang='en'> 例子9: 联系人的服务器递送更新的出席信息给联系人所有可用的资源: [to "balcony" resource...] from='romeo@https://www.doczj.com/doc/9414533608.html,/orchard' to='juliet@https://www.doczj.com/doc/9414533608.html,' xml:lang='en'> [to "chamber" resource...] from='romeo@https://www.doczj.com/doc/9414533608.html,/orchard' to='juliet@https://www.doczj.com/doc/9414533608.html,' xml:lang='en'> 例子10: 联系人的资源之一广播最后出席信息: 例子11: 联系人的服务器发送不可用出席信息给用户: type='unavailable' from='juliet@https://www.doczj.com/doc/9414533608.html,/balcony' to='romeo@https://www.doczj.com/doc/9414533608.html,/orchard'/> 例子12: 用户发送最后出席信息: type='unavailable' xml:lang='en'> 例子13: 用户的服务器广播不可用出席信息给联系人,包括用户直接向其发送出席信息的那个人: type='unavailable' from='romeo@https://www.doczj.com/doc/9414533608.html,/orchard' to='juliet@https://www.doczj.com/doc/9414533608.html,' xml:lang='en'> from='romeo@https://www.doczj.com/doc/9414533608.html,/orchard' to='nurse@https://www.doczj.com/doc/9414533608.html,' xml:lang='en'> 管理订阅 为了保护即时消息用户和任何其他实体的隐私, 出席信息和可用性信息仅向用户已批准的其他实体披露. 当一个用户同意其他用户可以看到它的出席信息, 这个实体被称为对于用户的出席信息有一个订阅. 订阅超越了会话; 实际上, 它一直存在直到订阅者取消订阅或被订阅者取消曾经授权的订阅为止. 在XMPP中订阅是通过发送包含特定属性的出席信息节来管理的. 注意: 在订阅和名册之间有重要的交互; 这些定义在名册条目和出席信息订阅的集成Integration of Roster Items and Presence Subscriptions (第八章), 而且读者必须参考那一章才能完整地理解出席信息订阅. 请求一个订阅 对另一个实体的出席信息的订阅请求是由发送一个类型为"subscribe"的出席信息节来开始的. 例子: 发送一个订阅请求: 关于客户端和服务器在订阅请求中的职责, 参考出席信息订阅Presence Subscriptions(第五章第一节第六小节). 处理一个订阅请求 当一个客户端从另一个实体接收到一个订阅请求, 它必须(MUST)批准这个请求(发送一个类型为"subscribed"的出席信息节)或拒绝这个请求(发送一个类型为"unsubscribed"的出席信息节). 例子: 批准一个订阅请求: 例子: 拒绝一个出席信息订阅的请求: 从另一个实体取消一个订阅 如果一个用户想取消一个曾经允许的订阅请求, 它发送一个类型为"unsubscribed"的出席信息节. 例子: 取消一个曾经允许的订阅请求: 取消对于另一个实体的出席信息的订阅 如果用户想取消对于另一个实体的出席信息的订阅, 它发送一个类型为"unsubscribe"的出席信息节. 例子: 取消对一个实体的出席信息的订阅: 名册管理 在XMPP中, 一个人的联系人列表被称为名册(roster), 它包括任意数量的特定名册条目, 每个名册条目被一个唯一的JID(通常格式是 注意: 在名册和订阅之间有重要的交互; 这些定义在名册条目和出席信息订阅的集成Integration of Roster Items and Presence Subscriptions (第八章), 而且读者必须参考那一章才能完整地理解名册管理. 语法和语义 名册使用IQ节来管理, 具体来说就是符合'jabber:iq:roster'名字空间的 在android里面用的smack包其实叫做asmack，该包提供了两种不同的连接方式：socket和httpclient。该并且提供了很多操作xmpp协议的API，也方便各种不同自定义协议的扩展。我们不需要自己重新去定义一套接收机制来扩展新的协议，只需继承然后在类里处理自己的协议就可以了。而本文今天主要说两点，一点就是消息是如何接收的，另一点就是消息是如何通知事件的。 总的思路 1.使用socket连接服务器 2.将XmlPullParser的数据源关联到socket的InputStream 3.启动线程不断循环处理消息 4.将接收到的消息解析xml处理封装好成一个Packet包 5.将包广播给所有注册事件监听的类 逐步击破 （声明在看下面的文章时，最好先理解一下smack的使用，这样才能达到深入的理解） （谨记：上图只显示本文章解释所要用到的类和方法，减缩了一些跟本文主题无关的代码，只留一条贯穿着从建立连接到接收消息的线。） 解析这块东西打算从最初的调用开始作为入口，抽丝剥茧，逐步揭开。 1. PacketListener packetListener = new PacketListener() { @Override public void processPacket(Packet packet) { System.out .println("Activity----processPacket"+ packet.toXML()); } }; PacketFilter packetFilter = new PacketFilter() { @Override 万方数据 万方数据 万方数据 基于XMPP协议和Openfire的即时通信系统的开发 作者：潘凤， 王华军， 苗放， 李刚 作者单位：潘凤(成都理工大学信息工程学院,四川,成都,610059;运城学院计算机科学与技术系)， 王华军,苗放(成都理工大学信息工程学院,四川,成都,610059)， 李刚(华商世纪(北京)科贸发 展股份有限公司) 刊名： 计算机时代 英文刊名：COMPUTER ERA 年，卷(期)：2008，(3) 被引用次数：1次 参考文献(5条) 1.许鼎即时通信四种协议简述 2003 2.庞怡即时通讯工具现状及发展趋势分析[期刊论文]-科技情报开发与经济 2006 3.Jason Kichten.李军用基于XML的即时消息开发Jabber 2003 4.Peter S A XMPP Instant Messaging and Presenee 2004 5.Jabber官方组织"Jabber::Protocol" 相似文献(6条) 1.学位论文付莎基于XMPP协议企业级IM的研究与实现2009 近年来即时通信技术的飞速发展使即时通信工具的应用更为广泛，给个人的网络生活、企业的日常办公都带来了极大的便利性与高效性。XMPP( eXtensible Messaging and Presence Protocol)可扩展消息与出席协议技术便是其中较为活跃的一种即时通信技术。由于即时通信工具在企业中的应用给企业的运营管理带来诸多便利，因而在企业中的应用越来越广泛，具有很高的研究与应用价值。 目前常用的即时通信软件的协议种类繁多，本文在研究比较了当前流行的几种协议之后，选用了基于可扩展标记语言XML的XMPP协议，由于其开放性、扩展性、安全性良好等诸多优势，并可以实现与使用其他协议的即时通信软件的互联互通，且发展前景良好，因而对于开发一款企业级即时通信系统有着十分明显的优势。本文从对XMPP协议的介绍与分析入手，首先简要介绍了XMPP协议及其发展，XMPP协议的特点，然后又深入介绍了XMPP协议的内容：XMPP协议的系统构架、地址空间、数据的传输结构、以及通信链路的建立过程等。在对协议进行了深入研究的基础上，根据本文的研究目标，针对企业级即时通信系统的特点进行需求分析，并设计与实现。在实现了即时通信的消息收发、名册管理、出席信息的交换等基本功能的基础上，着重研究了用户的管理控制问题、权限划分、可追溯性管理及功能性、扩展性的要求，实现了会议功能、文件传输，以及广播功能，模拟了与非XMPP系统进行交互的过程。在开源软件系统Openfire及Gloox库的支持基础上，最终设计并实现了一套完善的面向企业级的即时通信系统。 最后对系统进行了测试，完成了测试平台的搭建工作，建立相应的测试用例。系统实验测试的结果表明：系统功能完善、稳定，界面友好简洁，满足企业级即时通信系统的需求。 2.学位论文招俏春基于XMPP协议的即时通讯系统的研究2008 随着互联网的普及和发展，即时通讯已经成为人们交流的重要手段。目前有许多的IM系统，如AOL IM、Yakoo IM和MSN IM，它们使用了不同的技术，而且它们互不兼容。XMPP/Jabber的提出打破了传统即时通信系统之间无法实现互联互通的局面。XMPP对于即时通信是一个开放的基于xml的数据模型和协议，采用了分布式的网络体系机构，模块化可扩展的系统架构，使得扩展它的功能变得简单。 利用Jabber/XMPP的体系结构，构建了一个基于XMPP协议的即时通信系统，包括即时通信系统的客户端和服务器。其中服务器采用开源的Jabber服务器Openfire，客户端基于XMPP核心及扩展协议利用Google Talk的开发包libjingle进行研究开发。设计了一个与Openfire互联通信的客户端系统，实现与客户音的文字、语音、视频、文件及实时数据通信功能；研究了XMPP协议及其在协同通讯领域的应用。 介绍了即时通讯的现状、发展趋势，分析了客户端软件的开发环境和所要用到的几个相关技术。在此基础上设计出基于)(MPP协议的能与Jabber服务器Openfire实现互通的客户端软件的总体架构和基本模型，并对即时通讯客户端的具体设计进行了全方位的阐述：在XMPP流通信基础上的文字通信及扩展的群组通讯；基于JEP扩展协议Jingle协议完善了系统功能，进行了客户问的P2P(Peer-to-Peer，点对点)连接扩展，从而实现了可靠的实时语音视频、文件、实时数据等P2P通信。另外还对客户端设计中的几个关键问题，网络安全机制和带NAT的防火墙穿越等方面的进行了较为深入的研究，并论述了本系统所采用的方案。最后总结了本设计的工作与成果，并提出下一阶段的研究设想。 3.期刊论文路璐.王华军.苗放.李刚.Lu Lu.Wang Huajun.Miao Fang.Li Gang基于Jingle协议及Opnefire的语音通信原理与实现-办公自动化（综合版）2007(12) 本文对Jingle协议及Openfire开源项目进行研究和分析,在此基础上进行点对点语音通信原理的分析和实现,并指出该通信方式的优点和不足. 4.学位论文罗伟基于Android平台的即时通讯系统的研究与实现2009 随着移动通信与Internet的飞速发展及相互融合，GPRS使无线网络高速接入到Internet成为现实，移动用户从而可以享受到Internet提供的服务。即时通讯是基于互联网协议的应用程序，它能够使应用不同设备的用户进行通信，随着手机的不断普及以及性能的不断提升，为即时通讯系统从传统的PC机到手机的移植提高了很好的条件。而且在中国庞大的手机用户中，通过手机使用即时通讯软件的用户越来越多。当前的手机操作系统都过于封闭 ，各大即时通讯软件采用的通讯协议也不统一，而Android是基于Linux的开源的手机操作系统平台，XMPP是基于XML的开源的即时通讯协议，因此基于Android平台和XMPP协议开发即时通讯系统具有很好的应用前景。 本文给出了系统的研究背景，对当前手机操作系统、即时通讯软件和即时通讯协议的发展现状做了简单的介绍。进而详细的分析了Android的特征、架构以及Android应用的构成和工作机制，并对Android与其他手机操作系统进行了比较，说明了Android在手机操作系统中的优势。提出了系统的架构 ，以及系统服务器端和客户端的解决方案，采用开源的Openfire作为系统的即时通讯平台，实现移动客户端之间的即时通讯。对系统客户端的组成模块进行了介绍，对即时通讯协议XMPP以及系统的通讯机制进行了分析。针对当前通信数据的安全问题并结合本系统的特点，对IDEA数据加密算法进行了改进，提出了A—IDEA算法的设计，并对两种算法从几个方面进行了对比分析，对于图片文件的加密，采用A—IDEA与RSA算法相结合的方案。对服务器的运行流程进行了分析并对系统客户端进行了详细的设计与实现，对系统进行了部署和测试。 5.期刊论文剧忻.苗放.JU Xin.MIAO Fang基于MINA开发高性能网络应用程序——以实现XMPP协议 XMPP协议即时通讯(Openfire服务器版) 一、什么是XMPP XMPP(Extensible Messageing and Presence Protocol：可扩展消息与存在协议)是目前主流的IM(IM：instant messaging,即时消息)协议之一。 XMPP是一种基于标准通用标记语言的子集XML的协议，它继承了在XML 环境中灵活的发展性。 XMPP中定义了三个角色，客户端，服务器，网关。通信能够在这三者的任意两个之间双向发生。 服务器同时承担了客户端信息记录，连接管理和信息的路由功能。网关承担着与异构即时通信系统的互联互通，异构系统可以包括SMS(短信)，MSN，ICQ 等。 XMPP即时通信协议，采用C/S体系结构。基本的网络形式是客户端连接到服务器，然后由服务器去连接到另一个客户端进行两个客户端之间的通信。 而他们传输的是XML流。 XMPP工作原理说明: 所有从一个客户端到另一个客户端的消息和数据都要通过服务器。 1、客户端连接服务器 2、服务器利用本地目录系统的证书对其认证 3、客户端制定目标地址，让服务器告知目标状态 4、服务器查找，连接并进行相互认证 5、客户端间进行交互 二、搭建服务器(Openfire) 通过上述的了解，我们知道要想进行通信，我们必须要有一个服务器。服务器端采用Openfire作为服务器。 允许多个客户端同时登录并且并发的连接到一个服务器上。 服务器对每个客户端的连接进行认证，对认证通过的客户端创建会话，客户端与服务器端之间的通信就在该会话的上下文中进行。 首先安装Openfire 点击继续 点击安装 安装成功后再偏好设置中就会有Openfire的图标。点击Openfire的图标 XMPP协议分析-原理篇 XMPP协议简介 XMPP协议（Extensible Messaging and PresenceProtocol，可扩展消息处理现场协议）是一种基于XML的协议，目的是为了解决及时通信标准而提出来的，最早是在Jabber上实现的。它继承了在XML环境中灵活的发展性。因此，基于XMPP的应用具有超强的可扩展性。并且XML很易穿过防火墙，所以用XMPP构建的应用不易受到防火墙的阻碍。利用XMPP作为通用的传输机制，不同组织内的不同应用都可以进行有效的通信。 XMPP协议特点 1）所有XMPP信息都是以XML为基础的，信息交换的事实标准，扩展性强 2）XMPP系统是一个分布式系统，每台服务器控制自己的资源，但是如果需要，它能与外在的系统进行通 信。XMPP服务器利用开放的XML协议来进行S2S(Serverto Server)通信，就像在C2S(Client to Server)一样。相比之下，大多数的IM系统使用了只是支持C2S/S2C通信的协议，因此Jabber/XMPP服务器具有更大的灵活性。 3）XMPP协议是公开的，程序则开放源代码。定义了客户端和服务器端的交互要经由XML流。普通消息类型（message），如改变状态(presence)，传递消息内容或查询/更新(info/quey)应用则用每个指定的命名空间(namespace)来建立。 4）状态(Presence)在整个持久连接中。通过持久连接的有效维持，XMPP协议一直有在网络中维持存在和可用信息的能力。 5）XMPP允许建立并行的TCP套接字连接对所有连接上的客户端和服务器端。一旦建立连接，则只有当状态改变，例如存在的改变，通过这个连接传输数据。既然这个连接是持久的，那么设置、认证、状态查找功能都不用每次都重复执行。这种持久的套接字的连接使得XMPP能够更有效的支持高级的具有存在能力的应用在带宽和处理资源的使用中。 6）Jabber/XMPP系统是模块化的，而且Jabber/XMPP的设计强调如何实现可伸缩性、安全性和可扩展性。 XMPP协议分析 XMPP中定义了三个角色：客户端，服务器，网关。 通信能够在这三者的任意两个之间双向发生。服务器同时承担了客户端信息记录，连接管理和信息的路由功能。网关承担着与异构即时通信系统的互联互通，异构系统可以包括SMS （短信），MS N，IC Q等。基本的网络形式是单客户端通过TCP/IP连接到单服务器，然后在之上传输XML。 XMPP的基本网络结构如下： C1----S1---S2---C3 | C2----+--G1===FN1===F C1 符号表示：C1,C2,C3=XMPP客户端；S1,S2=XMPP；服务端G1=在XMPP和使用外部消息网络（非XMPP）的协议之间转换的网；FN1=外部消息网络；F C1=外部消息网络的客户端。 （1）服务器 竭诚为您提供优质文档/双击可除 gopher,协议 篇一：网络七层模型各层的协议 网络七层模型各层的协议 在互联网中实际使用的是tcp/ip参考模型。实际存在 的协议主要包括在：物理层、数据链路层、网络层、传输层和应用层。各协议也分别对应这5个层次而已。 要找出7个层次所对应的各协议，恐怕会话层和表示层的协议难找到啊。。 应用层 ·dhcp(动态主机分配协议) ·dns(域名解析） ·Ftp（Filetransferprotocol）文件传输协议 ·gopher（英文原义：theinternetgopherprotocol中 文释义：（RFc-1436）网际gopher协议） ·http（hypertexttransferprotocol）超文本传输协 议 ·imap4(internetmessageaccessprotocol4)即 internet信息访问协议的第4版本·iRc（internetRelaychat） 网络聊天协议 ·nntp（networknewstransportprotocol）RFc-977）网络新闻传输协议 ·xmpp可扩展消息处理现场协议 ·pop3(postofficeprotocol3)即邮局协议的第3个版本 ·sip信令控制协议 ·smtp（simplemailtransferprotocol）即简单邮件传输协议 ·snmp(simplenetworkmanagementprotocol,简单网络管理协议) ·ssh（secureshell）安全外壳协议 ·telnet远程登录协议 ·Rpc（Remoteprocedurecallprotocol）（RFc-1831）远程过程调用协议 ·Rtcp（Rtpcontrolprotocol）Rtp控制协议 ·Rtsp（Realtimestreamingprotocol）实时流传输协议 ·tls（transportlayersecurityprotocol）安全传输层协议 ·sdp(sessiondescriptionprotocol）会话描述协议 ·soap（simpleobjectaccessprotocol）简单对象访问 XMPP 协议 1. XMPP 优缺点 X MPP (Extensible Messaging and Presence Protocol) (前称Jabber) 是一种以 X ML 为基础的开放式即时通讯协议，是经由互联网工程工作小组 (IETF) 通过的互联网标准。[1] 1.1 XMPP 协议的优点 1.1.1 可扩展性 X MPP 的数据传输基于 X ML 格式，可扩展性强。X MPP 的核心协议栈 (Core Stack) 部分只定义了基础的 Presence，Message，Iq 等最主要数据格式和传输逻辑，更多的功能则通过定义扩展 (Extensions) 实现。 1.1.2 受 IETF 组织规范 Internet Engineering Task Force (IETF) 在2002年开始规范 X MPP 协议，使其协议的修订和扩展的添加都经过严格的流程审核，防止 X MPP 协议因缺乏标准而分裂。并且这也保证了 X MPP 协议是完全开放的。 1.1.3 应用广泛 X MPP 协议的应用比其他开放即时通讯协议更为广泛。较有名的使用 X MPP 协议的聊天服务有 Google Gtalk 和 Facebook Chat 等。此外，X MPP 在各平台下都有若干服务端、客户端和程序库的实现，二次开发时成本较低。 X MPP 协议的可扩展性和开放性是该协议被广泛应用的保证。 1.2 XMPP 协议的缺点 1.2.1 不内置支持二进制数据的传输 X MPP 的核心部分没有包含对二进制数据传输的支持，这使得 X MPP 的基本数据限定在文本文件范围内。X MPP 社区认为，X MPP 应该用于传输 meta 信息，辅助其他应用进行协议握手，X MPP 本身不应负担海量信息的传输。 RFC3920 可扩展的消息和出席信息协议（GMPP）:核心协议 关于本文的说明 本文为互联网社区定义了一个互联网标准跟踪协议，并且申请讨论协议和提出了改进的建议。请参照“互联网官方协议标准”的最新版本（ STD1 ）获得这个协议的标准化进程和状态。本文可以不受限制的分发。 版权声明 本文版权属于互联网社区（C）TheInternetSocietP（20GG）. 摘要 本文定义了可扩展消息和出席信息协议（GMPP ）的核心功能，这个协议采用 GML流实现在任意两个网络终端接近实时的交换结构化信息。GMPP提供一个 通用的可扩展的框架来交换GML数据，它主要用来建立即时消息和出席信息应用以实现RFC2779的需求。 目录 1. 绪论 2. 通用的架构 3. 地址空间 4. GML 流 5. TLS的使用 6. SASL的使用 7. 资源绑定 8. 服务器回拨 9. GML 节 10. 服务器处理GML节的规则 11. GMPP中的GML用法 12. 核心的兼容性要求 13. 国际化事项 14. 安全性事项 15. IANA 事项 16. 参考 1. 绪论 1.1. 概览 GMPP是一个开放式的GML协议，设计用于准实时消息和出席信息以及请求- 响应服务。其基本的语法和语义最初主要是由Jabber开放源代码社区于1999 年开发的。20GG年，GMPP工作组被授权接手开发和改编 Jabber协议以适应 IETF的消息和出席信息技术。作为GMPP工作组的成果，本文定义了 GMPP1.0 的核心功能；在RFC2779[IMP-REQS]中指定的提供即时消息和出席信息功能的扩展，定义在GMPP-IM 协议 物联网四大协议物联网协议 协议一：物联网协议XMPP XMPP是一种基于标准通用标记语言的子集XML的协议，它继承了在XML环境中灵活的发展性。因此，基于XMPP的应用具有超强的可扩展性。经过扩展以后的XMPP可以通过发送扩展的信息来处理用户的需求，以及在XMPP的顶端建立如内容发布系统和基于地址的服务等应用程序。而且，XMPP包含了针对服务器端的软件协议，使之能与另一个进行通话，这使得开发者更容易建立客户应用程序或给一个配好系统添加功能。 基本网络结构 XMPP中定义了三个角色，客户端，服务器，网关。通信能够在这三者的任意两个之间双向发生。服务器同时承担了客户端信息记录，连接管理和信息的路由功能。网关承担着与异构即时通信系统的互联互通，异构系统可以包括SMS（短信），MSN，ICQ等。基本的网络形式是单客户端通过TCP/IP连接到单服务器，然后在之上传输XML。 工作原理 XMPP核心协议通信的基本模式就是先建立一个stream，然后协商一堆安全之类的东西，中间通信过程就是客户端发送XML Stanza，一个接一个的。服务器根据客户端发送的信息以及程序的逻辑，发送XML Stanza给客户端。但是这个过程并不是一问一答的，任何时候都有可能从一方发信给另外一方。通信的最后阶段是关闭流，关闭TCP/IP 连接。 功能 传输的是与即时通讯相关的指令。在以前这些命令要么用2进制的形式发送（比如QQ），要么用纯文本指令加空格加参数加换行符的方式发送（比如MSN）。而XMPP传输的即时通讯指令的逻辑与以往相仿，只是协议的形式变成了XML格式的纯文本。 优点 XMPP协议是自由、开放、公开的，并且易于了解。而且在客户端、服务器、组件、源码库等方面，都已经各自有多种实现。 缺点 网络通信过程中数据冗余率非常高，网络流量中70% 都消耗在 XMPP 协议层了。对于物联网来说，大量计算能力有限且工作在低带宽、不可靠网络的远程传感器和控制设备，省电、省流量是所有底层服务的一个关键技术指标，XMPP协议看起来已经落后了。 XMPP 协议工作流程详解 分类：翻译文章2014-04-23 11:11 2221人阅读评论(0) 收藏举报原文: https://www.doczj.com/doc/9414533608.html,.au/content/how-xmpp-works-step-step 作者: Yilun Fan, 日期2011-01-05 13:09 XMPP 核心协议https://www.doczj.com/doc/9414533608.html,/rfcs/rfc3920.html XMPP 要点. ? 1. 客户端(C) 和服务器端(S) 通过TCP连接5222端口进行全双工通信. ? 2. XMPP 信息均包含在XML streams中.一个XMPP会话, 开始于 深入学习XMPP协议 一．XMPP（协议简介） XMPP协议（Extensible Messaging and PresenceProtocol，可扩展消息处理现场协议）是一种基于XML的协议，目的是为了解决及时通信标准而提出来的，最早是在Jabber上实现的。它继承了在XML 环境中灵活的发展性。因此，基于XMPP的应用具有超强的可扩展性。并且XML很易穿过防火墙，所以用XMPP构建的应用不易受到防火墙的阻碍。利用XMPP作为通用的传输机制，不同组织内的不同应用都可以进行有效的通信。 二．IM（即时通讯软件简介） Instant Messenger，及时通信软件，就是大家使用的QQ、MSN Messenger和Gtalk等等。其中Gtalk 就是基于XMPP 协议的一个实现，其他的则不是。当前IM 几乎作为每个上网者必然使用的工具，在国外的大型企业中有一些企业级的IM应用，但是其商业价值还没完全发挥出来。设想既然XMPP 协议是一个公开的协议，那么每个企业都可以利用它来开发适合本身企业工作，提高自身生产效率的IM；甚至，你还可以在网络游戏中集成这种通信软件，不但让你可以边游戏边聊天，也可以开发出适合游戏本身的IM 应用，比如说一些游戏关键场景提醒功能，团队语音交流等等都可以基于IM来实现。 三．本文主要内容 本文主要讲解在android使用xmpp协议进行即时通信，所涉及3个主要的东西，它们是openfire、smack和spark，这个三个东东结合起来就是完整的xmpp IM实现，这里简单介绍一下这3个东东在下文的作用： openfire主要是作为服务器，负责管理客户端的通信连接，以及提供客户端一些通信信息和连接信息。 Smack主要是xmpp协议的实现，提供了一套很好的api，所以下面操作xmpp都是通过使用smack的api来实现，当然因为是在android里，所以使用的是asmack这个包，里面方法跟smack包差不多。 Spark 是IM客户端的实现，其实就是使用了smack 的api实现的。 数据通讯具体实现的流程： 基于XMPP协议的即时通信系统服务器集群的研究 陈武，杨世达 武汉理工大学计算机学院，武汉（430071） E-mail：chenwu0211@https://www.doczj.com/doc/9414533608.html, 摘要：本文描述了在实现基于xmpp协议的即时通信系统的服务器集群时遇到的关键性问题，从安全、性能和通用性方面考虑提出了解决方案，重点介绍了服务器间的寻址和路由机制、服务期间通信的安全机制、故障转移机制。 关键词：xmpp；集群；服务器；安全 中图分类号：TP319 文献标识码：A 1. 引言 XMPP是一个开放的、基于XML的数据模型和协议。对用户而言，在面对现有的各种即时通讯服务，没有统一标准，无法实现互联互通的局面下，XMPP 的出现实现了整个即时通信服务协议的统一。它提供了一种开放式的、基于XML的、能在分布式网络中传输即时消息和在线发现的标准，并解决了不同IM 系统间互操作的问题[1]，但是对于即时消息系统服务器集群的实现并没有统一的标准，各个系统服务器集群的实现不尽相同。 2. 集群技术 2.1集群的概念 简单的说，集群就是两台或多台计算机或节点在一个群组内共同工作。与单独工作的计算机相比，集群能够提供更高的可用性和可扩充性。集群中的每个节点通常都拥有自己的资源（处理器、内存、操作系统），并对自己的用户集负责。集群中的每一个服务器都相当于一个结点，各个结点之间通过网络互联，并且在各个节点上都有集群软件用以实现节结点之间寻址和路由，同时保证各节点间通信时的安全，当某个结点出现故障时能实现故障转移和动态的负载平衡。 2.2集群的体系结构 每个用户都有自己的本地服务器，并从该服务器上接受信息, 所有从一个客户端发给另一个客户端的消息和数据都必须通过服务端。每一个服务器都独立于其他服务器,并且拥有其自身的用户列表，通过Internet这些服务器构成了一个分布式网络。服务器通过发送一个探针了解一个用户是否在线，这是实现即时通信的关键。当用户量不是很大时，一台服务器就可以承受，但当用户量超过服务器所能承受的极限时，我们需要多台服务器来分摊负荷，这就带来了新的问题：但不同服务器下的客户端通信时，服务器之间的交互方式。这就要引入服务器集群的概念。集群就是两台或多台计算机或节点共同工作，与单独的计算机相比，集群具有高效性、稳定性和安全性。集群由授权服务器、应用程序服务器和数据库服务器组成，其结构如下所示： 网络协议为计算机网络中进行数据交换而建立的规则、标准或约定的集合。例如，网络中一个微机用户和一个大型主机的操作员进行通信，由于这两个数据终端所用字符集不同，因此操作员所输入的命令彼此不认识。为了能进行通信，规定每个终端都要将各自字符集中的字符先变换为标准字符集的字符后，才进入网络传送，到达目的终端之后，再变换为该终端字符集的字符。当然，对于不相容终端，除了需变换字符集字符外还需转换其他特性，如显示格式、行长、行数、屏幕滚动方式等也需作相应的变换。 简介 协议是用来描述进程之间信息交换数据时的规则术语（参见“法律学”对于“协议”的定义）。在计算机网络中，两个相互通信的实体处在不同的地理位置，其上的两个进程相互通信，需要通过交换信息来协调它们的动作达到同步，而信息的交换必须按照预先共同约定好的规则进行。 要素 网络协议是由三个要素组成： 1. 语义：语义是解释控制信息每个部分的意义。它规定了需要发出何种控制信息，以及完成 的动作与做出什么样的响应。 2. 语法：语法是用户数据与控制信息的结构与格式，以及数据出现的顺序。 3. 时序：时序是对事件发生顺序的详细说明。（也可称为“同步”）。 人们形象地把这三个要素描述为：语义表示要做什么，语法表示要怎么做，时序表示做的顺序。 工作方式 网络上的计算机之间又是如何交换信息的呢？就像我们说话用某种语言一样，在网络上的各台计算机之间也有一种语言，这就是网络协议，[4]不同的计算机之间必须使用相同的网络协议才能进行通信。 网络协议是网络上所有设备（网络服务器、计算机及交换机、路由器、防火墙等）之间通信规则的集合，它规定了通信时信息必须采用的格式和这些格式的意义。大多数网络都采用分层的体系结构，每一层都建立在它的下层之上，向它的上一层提供一定的服务，而把如何实现这一服务的细节对上一层加以屏蔽。一台设备上的第n层与另一台设备上的第n层进行通信的规则就是第n层协议。在网络的各层中存在着许多协议，接收方和发送方同层的协议必须一致，否则一方将无法识别另一方发出的信息。网络协议使网络上各种 物联网的七大通信协议 通信对物联网来说十分常用且关键，无论是近距离无线传输技术还是移动通信技术，都影响着物联网的发展。而在通信中，通信协议尤其重要，是双方实体完成通信或服务所必须遵循的规则和约定。 在物联网协议中，我们一般分为两大类，一类是传输协议，一类是通信协议。传输协议一般负责子网内设备间的组网及通信；通信协议则主要是运行在传统互联网TCP/IP协议之上的设备通讯协议，负责设备通过互联网进行数据交换及通信。那么物联网都有哪些通信协议呢？随着iBeacon生产厂家-云里物里科技一起来看下吧 物联网七大通信协议 一、REST/HTTP(松耦合服务调用) REST即表述性状态传递，是基于HTTP协议开发的一种通信风格。 适用范围：REST/HTTP主要为了简化互联网中的系统架构，快速实现客户端和服务器之间交互的松耦合，降低了客户端和服务器之间的交互延迟。因此适合在物联网的应用层面，通过REST开放物联网中资源，实现服务被其他应用所调用。 特点： 1.REST指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是RESTful。 2.客户端和服务器之间的交互在请求之间是无状态的。 3.在服务器端，应用程序状态和功能可以分为各种资源，它向客户端公开，每个资源都使用URI得到一个唯一的地址。所有资源都共享统一的界面，以便在客户端和服务器之间传输状态。 4.使用的是标准的HTTP方法，比如：GET、PUT、POST和DELETE。 二、CoAP协议 CoAP(Constrained Application Protocol)，受限应用协议，应用于无线传感网中协议。 适用范围：CoAP是简化了HTTP协议的RESTful API，CoAP是6LowPAN协议栈中的应用层协议，它适用于在资源受限的通信的IP网络。 三、MQTT协议(低带宽) MQTT(Message Queuing Telemetry Transport)，消息队列遥测传输，由IBM 开发的即时通讯协议，相比来说比较适合物联网场景的通讯协议。MQTT协议采用发布/订阅模式，所有的物联网终端都通过TCP连接到云端，云端通过主题的方式管理各个设备关注的通讯内容，负责将设备与设备之间消息的转发。 适用范围：在低带宽、不可靠的网络下提供基于云平台的远程设备的数据传输和监控。 PMON协议通讯程序方案书 编制人：李丁山 编制日期：2006-6-15 评审人： 评审日期： 修改历史 评审历史 文档目录 PMON协议通讯程序方案书 (1) 修改历史 (2) 评审历史 (2) 项目背景 (4) 需求简介 (4) 技术解决方案 (5) 开发平台 (5) 系统结构 (5) 报文发送 (6) 报文接收 (7) Life报文发送 (7) Life报文接收 (7) 项目管理方案 (8) 项目管理工具 (8) 项目规模估算 (8) 项目计划 (8) 项目风险 (9) 项目背景 上海大众汽车公司目前生产控制数据的通讯协议是基于德国提供的应用协议PMON，该协议建立在UDP/IP通讯协议基础上，将生产过程数据发送到生产控制服务系统，并从生产控制服务系统获得反馈数据。 由于该协议由德方提供，在应用开发中，只有得到德方的支持才能建立通讯，无论从项目的开发成本，还是项目将来的维护，扩充都非常的昂贵且不方便。因此，上海大众希望能够在充分研究PMON协议的基础上，自主开发一套基于PMON应用协议的通讯程序，为将来的生产应用系统的开发提供公共的通讯基础模块系统。 需求简介 基于目前的理解，本通讯系统需要完成以下功能： 1．通讯连接维护 a)建立UDP网络连接 b)通过指令，建立和PMON Server的应用连接 c)通过指令，断开和PMON Server的应用连接 2．发送数据 a)发送生产过程数据 b)发送协调数据（报文ID） c)分段发送大批量数据 d)发送心跳（Life）数据 3．接受数据 a)接受心跳（Life）数据 b)接受应答数据 c)超时等待数据接受 d)不等待接受数据 e)一直等待接受数据 4．查询通讯的状况 a)通过心跳报文定时检查通讯连接状态 5．通讯队列维护 a)创建通讯队列 b)打开队列 c)关闭队列 d)查询发送队列中的报文数 XMPP协议使用开源jabber(XMPP)协议及openfire架设内部即时通讯服务 分类：C# jabber/XMPP 2010-12-11 14:59 89人阅读评论(0) 收藏举报Jabber 是著名的即时通讯服务服务器，它是一个自由开源软件，能让用户自己架即时通讯服务器，可以在Internet上应用，也可以在局域网中应用。 XMPP（可扩展消息处理现场协议）是基于可扩展标记语言（XML）的协议，它用于即时消息（IM）以及在线现场探测。它在促进服务器之间的准即时操作。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。XMPP的技术来自于Jabber，其实它是 Jabber 的核心协定，所以XMPP有时被误称为Jabber协议。Jabber是一个基于XMPP协议的IM应用，除Jabber 之外，XMPP还支持很多应用。下面就是如何架设内部即时通讯服务的步骤： 第一步：安装Jabber服务器软件 Jabber服务软件有很多，具体可以参考jabber官方网站的列表： Jabber官网地址：https://www.doczj.com/doc/9414533608.html,/ 常用Jabber服务器软件：https://www.doczj.com/doc/9414533608.html,/software/servers.shtml 其中最为方便安装搭建的无疑是Openfire(Wildfire)，一款基于GPL协议开源软件，Openfire有linux、windows和MAC的不同版本，软件需要java环境支持，不过软件本身自带了环境包，你可以根据你的需要下载不同的版本。 下载地址：https://www.doczj.com/doc/9414533608.html,/downloads/index.jsp#openfire 最新版本：Openfire 3.3.2 1、Windows版本安装方法： 下载：openfire_3_3_2.exe带java环境版本 安装：直接运行安装文件，程序默认安装至c:/Program Files/Openfire 运行：/bin/openfire.exe 2、Linux/Unix版本安装方法 如果使用rpm包安装，下载：openfire-3.3.2-1.i386.rpm 运行： #rpm -ivh openfire_3_0_0.rpm 默认安装路径位于：/opt/openfire 使用源码包安装，下载：openfire_3_0_0.tar.gz（不带java环境，请自行安装） #tar -xzvf openfire_3_0_0.tar.gz # mv openfire /opt 启动方法： #/opt/openfire/bin/openfire.sh 第二步：配置jabber服务器 Openfire（Wildfire）支持完全的web安装，如果你在本地按安装只需要在浏览器中输入 http://localhost:9090（远程服务器为http://你的服务器地址:9090）即可开始即时通讯服务器配置。（1）语言选择：中文简体xmpp协议的使用
基于XMPP协议和Openfire的即时通信系统的开发
XMPP协议即时通讯(Openfire服务器版)
XMPP协议分析-原理篇
gopher,协议
XMPP 协议
RFC3920(XMPP协议)中文版
物联网四大协议
XMPP 协议工作流程
Android基于XMPP协议的数据推送技术
基于XMPP协议的即时通信系统服务器集群的研究
什么是网络协议
物联网的七大通信协议
PMON协议通讯程序方案书
XMPP协议使用开源jabber(XMPP)协议及openfire架设内部即时通讯服务
相关主题
文本预览