BlogJava-赢在执行-文章分类-XMPP

XMPP初解

飛雪(leo) — Sun, 31 Dec 2006 05:17:00 GMT

1、什么是XMPP ？
XMPP：即Extensible Messaging and Presence Protocol，其前身是Jabber，一个开源形式组织产生的网络即时通信协议。XMPP目前被IETF国际标准组织完成了标准化工作。标准化的核心结果分为两部分；
核心的XML流传输协议
基于XML流传输的即时通讯扩展应用
XMPP的核心XML流传输协议的定义使得XMPP能够在一个比以往网络通信协议更规范的平台上。借助于XML易于解析和阅读的特性，使得XMPP的协议能够非常漂亮。
XMPP的即时通讯扩展应用部分是根据IETF在这之前对即时通讯的一个抽象定义的，与其他业已得到广泛使用的即时通讯协议，诸如AIM，QQ等有功能完整，完善等先进性。

2、XMPP的基本网络结构是怎样的？
XMPP中定义了三个角色，客户端，服务器，网关。通信能够在这三者的任意两个之间双向发生。服务器同时承担了客户端信息记录，连接管理和信息的路由功能。网关承担着与异构即时通信系统的互联互通，异构系统可以包括SMS（短信），MSN，ICQ等。基本的网络形式是单客户端通过TCP/IP连接到单服务器，然后在之上传输XML。

3、XMPP通过TCP传什么了？
传输的是与即时通讯相关的指令。在以前这些命令要么用2进制的形式发送（比如QQ），要么用纯文本指令加空格加参数加换行苻的方式发送（比如MSN）。而XMPP传输的即时通讯指令的逻辑与以往相仿，只是协议的形式变成了XML格式的纯文本。这不但使得解析容易了，人也容易阅读了，方便了开发和查错。而XMPP的核心部分就是一个在网络上分片断发送XML的流协议。这个流协议是XMPP的即时通讯指令的传递基础，也是一个非常重要的可以被进一步利用的网络基础协议。所以可以说，XMPP用TCP传的是XML流。

4、举个例子看看所谓的XML流是什么样子的？
客户端：
              to='example.com'
       xmlns='jabber:client'
       xmlns:stream='http://etherx.jabber.org/streams'
       version='1.0'>
服务器：
              from='example.com'
       id='someid'
       xmlns='jabber:client'
       xmlns:stream='http://etherx.jabber.org/streams'
       version='1.0'>
...其他通信...
客户端：from='juliet@example.com'
              to='romeo@example.net'
              xml:lang='en'>
客户端： Art thou not Romeo, and a Montague?
客户端：
服务器： from='romeo@example.net'
              to='juliet@example.com'
              xml:lang='en'>
服务器：Neither, fair saint, if either thee dislike.
服务器：
客户端：
服务器：
以文档的观点来看，客户端或服务器发送的所有XML文本连缀在一起，从到构成了一个完整的XML文档。其中的stream标签就是所谓的XML Stream。在与中间的那些...这样的XML元素就是所谓的XML Stanza（XML节）。XMPP核心协议通信的基本模式就是先建立一个stream，然后协商一堆安全之类的东西，中间通信过程就是客户端发送XML Stanza，一个接一个的。服务器根据客户端发送的信息以及程序的逻辑，发送XML Stanza给客户端。但是这个过程并不是一问一答的，任何时候都有可能从一个方发信给另外一方。通信的最后阶段是关闭流，关闭TCP/IP连接。
GTalk所遵循的协议---XMPP

前几天Google发布了一款名叫Google Talk的即时通讯软件，这款软件的买点卖点之一就是XMPP。那，什么是XMPP呢？
　　可扩展通讯和表示协议 (XMPP) 可用于服务类实时通讯、表示和需求 - 响应服务中的 XML 数据元流式传输。XMPP 以 Jabber 协议为基础，而 Jabber 是即时通讯中常用的开放式协议。
　　尽管 XMPP 没有完全溶合进任何特定的网络架构之中，但是通过客户机/服务器架构，它还是经常被采用，因为客户机需要使用 XMPP 经过 TCP 连接访问服务器，而服务器之间也是通过 TCP 连接进行通信的。服务器可起到 XMPP 通讯的智能提取层的作用。许多客户机直接通过 TCP 连接与服务器相连，并使用 XMPP 来充分使用服务器和任何相关服务所提供的功能。同时连接到服务器的可能有多种资源，它们代表各自已获授权的客户机。对于客户机和服务器之间的连接，推荐使用的端口号为 5222 。网关是一种有着特殊用途的服务器端服务，它的主要功能是在异构通讯系统协议之中解析 XMPP ，同时还要在 XMPP 之中解析返回的数据，如以下各各种服务的网关：电子邮件、国际互联网中继聊天（IRC）、SIMPLE、短信息服务（SMS）和现存的各种即时通讯服务，包括 AIM、ICQ、MSN Messenger 和 Yahoo! Instant Messenger 等。
　　两个基本概念 — XML 数据流和 XML 节使得较小结构化信息的有效负载可以在敏感于数据传输的实体间进行迅速的异步传输。一个 XML 数据流就像一种容器，可应用在任何两个网络实体间 XML 数据元的交换。XML 节是结构化信息的独立单元，通过 XML 数据流从一个实体发送到另一个实体。
　　XMPP 中包含了一种用于防范数据流被窜改和偷听的办法。这种信道加密的办法使用了传输层安全协议（TLS），连同其扩展协议 STARTTLS 。这种扩展与其它协议的扩展是同一模式的，如 IMAP、POP3 和 ACAP 等协议。XMPP 中还包含一种对数据流进行验证的办法，并采用了简单验证和安全层协议（SASL）中 XMPP 的特定框架。

协议结构
　　XML 数据流在所有 XML 节的传送会话过程中起到一种包络的作用。我们可以采用一种单纯的方式来表示这个过程：
|--------------------|
|            |
|--------------------|
|          |
|             |
|         |
|--------------------|
| |
| |
| |
|--------------------|
| |
| |
| |
|--------------------|
| ... |
|--------------------|
| |
|--------------------|

飛雪(leo) 2006-12-31 13:17 发表评论

开放的XMPP

飛雪(leo) — Sun, 31 Dec 2006 05:08:00 GMT

基于RFC 3920，RFC 2779等标准协议的研究，一点个人体会

基于XMPP的统一消息模型

好久没写文章了，感觉有点累，终于，看到了UU在招人，竟然要求最好是BLOG作为简历，所以为之一触，补一下自己的blog。

规划了很久的统一消息模型，终于在一个图上表现完了：）。。。

为了统一各个系统中的消息，计划采用以XMPP协议为基础的统一消息系统；在系统上构建以axis为基础的web service来提供相关的接口标准，这样能实现吗？

能统一什么？

·统一各个系统的消息

·统一邮件

·统一的短信

·统一的VOIP呼叫

·统一基于T.38协议的网络传真

·统一一切该统一的

支持什么操作系统？

Linux、Windows

支持的数据库？

DB2、ORACLE、MS SQL 、MY SQL、HSQL

能与什么系统统一能？

·基于WEB的应用系统（ASP、PHP、JSP）

·主流开发语言编写的应用系统（C、VB、DELPHI....）

基于开放的axis作为web service可以很方便的为其他系统提供统一的标准及接口，但是会面临一个问题：别人的系统为什么要和你统一起来呢？这个问题要思考....

OA、ERP、CMS等都面临这个问题，统一的消息机制是他们急需的，而对于企业，各个系统中消息的统一，以及完善的通知手段（包括文字、邮件、短信、传真、电话等）是必须的。

使用VoIP相关功能，我们可以建立多种应用服务，例如VoIP+TTS构件自动语音留言、VoIP多方电话会议等。

飛雪(leo) 2006-12-31 13:08 发表评论

RFC 3920 之 XMPP

飛雪(leo) — Sun, 31 Dec 2006 05:05:00 GMT

1 、 Extensible Messaging and Presence Protocol (XMPP): Core

1.1. Status of this Memo/ 说明

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

本文档详细说明了应用于 Internet 通讯的标准协议。对于本协议的更新的一些需求讨论和建议，请提交当前版本到“国际标准协议组织”。本文档分发不受限制。

1.2. Copyright Notice/ 版权申明

1.3. Abstract/ 概要

This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779.

本文定义了 XMPP 协议的核心特性。 XMPP 是基于 XML 流元素扩展的，它旨在向两个网络终端在近乎实时的情况下交换结构信息。 XMPP 也提供了一个没有显著特点的，可扩展的 XML 数据交换的框架结构模型。在 RFC 2779 标准定义的需求下，它应用于建立即时通讯和即时会议的应用程序。

1.4. Table of Contents/ 目录

1. Introduction/ 简介

2. Generalized Architecture/ 通用的结构

3. Addressing Scheme/ 地址配置

4. XML Streams/ XML 流

5. Use of TLS/ TSL 的应用

6. Use of SASL / SASL 的应用

7. Resource Binding / 资源绑定

8. Server Dialback / 服务回叫

9. XML Stanzas / XML 节

10. Server Rules for Handling XML Stanzas / XML 操作的服务规则

11. XML Usage within XMPP / XMPP 的 XML 用法

12. Core Compliance Requirements / 核心需求

13. Internationalization Considerations / 国际化考虑

14. Security Considerations / 安全考虑

15. IANA Considerations / IANA 考虑

16. References / 参考文献

17. Nodeprep / 节点命名

· B. Resourceprep / 资源命名

· C. XML Schemas / XML 计划

· D. Differences Between Core Jabber Protocols and XMPP / JABBER 和 XMPP 核心协议的区别

· Contributors/ 贡献者

· Acknowledgements/ 知识准备

· Author's Address/ 作者地址

· Full Copyright Statement/ 版权申明待续.........

1.4 1. Introduction/简介

1.4 1.1 Overview/综述

The Extensible Messaging and Presence Protocol (XMPP) is an open Extensible Markup Language [XML] protocol for near-real-time messaging, presence, and request-response services. The basic syntax and semantics were developed originally within the Jabber open-source community, mainly in 1999. In 2002, the XMPP WG was chartered with developing an adaptation of the Jabber protocol that would be suitable as an IETF instant messaging (IM) and presence technology. As a result of work by the XMPP WG, the current memo defines the core features of XMPP 1.0; the extensions required to provide the instant messaging and presence functionality defined in RFC 2779 [IMP-REQS] are specified in the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence [XMPP-IM].

xmpp是一个开放的基于xml的提供近乎实时消息、现场勘察和请求应答服务的协议。它最初是由jabber开源社区在大约 1999年发起并一直领导的即时消息的实时系统，在2002年，xmpp WG 。作为xmppWG的工作结果，当前备忘录定义了xmpp1.0的核心特征;在这个扩展部要求提供定义在<>的即时消息和现场勘察功能，是列在xmpp 中: [xmpp-im]。

1.4 1.2 Terminology/术语

The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [TERMS].

下面大写的关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "REC OMMENDED", "MAY", and "OPTIONAL" 在这篇文档中的意义请参见RFC 2119

1.4 2. Generalized Architecture/通用的结构

1.4 2.1 Overview/综述

Although XMPP is not wedded to any specific network architecture, to date it usually has been implemented via a client-server architecture wherein a client utilizing XMPP accesses a server over a [TCP] connection, and servers also communicate with each other over TCP connections.

The following diagram provides a high-level overview of this architecture (where "-" represents communications that use XMPP and "=" represents communications that use any other protocol).

C1---S1---S2--C3

C2---+---G1==============FN1==================FC1

The symbols are as follows:

·C1, C2, C3 = XMPP clients

·S1, S2 = XMPP servers

·G1 = A gateway that translates between XMPP and the protocol(s)

used on a foreign (non-XMPP) messaging network

·FN1 = A foreign messaging network

·FC1 = A client on a foreign messaging network

尽管xmpp不想与任何特殊的网络体系机构相结合，但它通常是基于c/s架构的，其中一个客户端通过一个tcp连接按着 xmpp 访问一个服务器，服务器同样也是通过tcp与其它实体通信。

下面的图表提供了这个体系机构的高层视图(--代表用xmpp进行通信，=代表是其它协议进行通信 )。

C1---S1---S2--C3

C2---+---G1==============FN1==================FC1

·C1,C2,C3 代表 XMPP客户端

·S1,S2代表XMPP服务器

·G1代表一个网关，它XMPP和其它外部(非xmpp)消息网络之间的翻译。

·FN1 代表一个外部消息网络

·FC1 代表一个外部消息网络的客户端。待续.........

1.4 2.2. Server/服务器

A server acts as an intelligent abstraction layer for XMPP communications. Its primary responsibilities are:

·to manage connections from or sessions for other entities, in the form of XML streams (Section 4) to and from authorized clients, servers, and other entities

·to route appropriately-addressed XML stanzas (Section 9) among such entities over XML streams

Most XMPP-compliant servers also assume responsibility for the storage of data that is used by clients (e.g., contact lists for users of XMPP-based instant messaging and presence applications); in this case, the XML data is processed directly by the server itself on behalf of the client and is not routed to another entity.

一个服务担当一个XMPP通信的智能提取层，这主要负责：

·管理一个来自其它通信实体的以xml流方式的连接或会话，它可以来自于授权的客户端、服务器、或者其它通信实体

·路由在基于xml流实体中具有正确地址的xml节( 第九节)

大多数的支持xmpp的服务器也可能为用户担任数据存储的职责( 如用户的联系列表);既然这样，服务器代表用户直接处理xml数据，而不被路由到另一个实体。

1.4 2.3 Client/客户端

Most clients connect directly to a server over a [TCP] connection and use XMPP to take full advantage of the functionality provided by a server and any associated services. Multiple resources (e.g., devices or locations) MAY connect simultaneously to a server on behalf of each authorized client, with each resource differentiated by the resource identifier of an XMPP address (e.g., vs. ) as defined under Addressing Scheme (Section 3). The RECOMMENDED port for connections between a client and a server is 5222, as registered with the IANA (see Port Numbers (Section 15.9)).

大多数的客户端直接通过tcp与服务器连接，用XMPP协议充分利用一个服务和任何相关的服务提供的功能。多个的资源(如设备或地区)可能同时连接到一个服务器，各自代表的一个授权的客户，它们通过XMPP地址(如 <node@domain/home> 和 <node@domain/work>)的resource标识符来区别。推荐的连接端口为5222, 它已向IANA注册。

1.4 2.4 Gateway/网关

A gateway is a special-purpose server-side service whose primary function is to translate XMPP into the protocol used by a foreign (non-XMPP) messaging system, as well as to translate the return data back into XMPP. Examples are gateways to email (see [SMTP]), Internet Relay Chat (see [IRC]), SIMPLE (see [SIMPLE]), Short Message Service (SMS), and legacy instant messaging services such as AIM, ICQ, MSN Messenger, and Yahoo! Instant Messenger. Communications between gateways and servers, and between gateways and the foreign messaging system, are not defined in this document.

一个网关是服务器上的一个具有特殊目的的服务。它主要的功能是与外部消息系统通信时，将xmpp数据翻译成该系统的协议数据，同是将该系统返回的数据翻译成xmpp数据。例如email, irc, SIMPLE,SMS, 和其它的即时消息如 AIM,ICQ, MSN Messenger, Yahoo!.网关与服务器之间的通信和网关与外部消息系统之间的通信的定义不在这篇文档中。

1.4 2.5 Network/网络

Because each server is identified by a network address and because server-to-server communications are a straightforward extension of the client-to-server protocol, in practice, the system consists of a network of servers that inter-communicate. Thus, for example, < juliet@example.com > is able to exchange messages, presence, and other information with < romeo@example.net >. This pattern is familiar from messaging protocols (such as [SMTP]) that make use of network addressing standards. Communications between any two servers are OPTIONAL. If enabled, such communications SHOULD occur over XML streams that are bound to [TCP] connections. The RECOMMENDED port for connections between servers is 5269, as registered with the IANA (see Port Numbers (Section 15.9)).

因为每一个服务器都可以通过一个网络地址来标识，同时因为服务器之间的通信是客户端与服务器之间的通信协议的一个直接的扩展，在实践中，系统由交互通信的服务器网络组成。因此，例如< juliet@example.com >能够与< romeo@example.net > 交换消息、现场勘察和其它信息。这种模式在使用网络地址标准的消息通信协议 (如SMTP)中是常见的，任何两个通信是可选的。如开启，那么通信在基于xml流上发生，它一定要建立TCP连接。推荐的连接端口为5269, 它已向IANA注册。

1.4 3. Addressing Scheme/地址配置

1.4 3.1 Overview/综述

An entity is anything that can be considered a network endpoint (i.e., an ID on the network) and that can communicate using XMPP. All such entities are uniquely addressable in a form that is consistent with RFC 2396 [URI]. For historical reasons, the address of an XMPP entity is called a Jabber Identifier or JID. A valid JID contains a set of ordered elements formed of a domain identifier, node identifier, and resource identifier.

The syntax for a JID is defined below using the Augmented Backus-Naur Form as defined in [ABNF]. (The IPv4address and IPv6address rules are defined in Appendix B of [IPv6]; the allowable character sequences that conform to the node rule are defined by the Nodeprep profile of [STRINGPREP] as documented in Appendix A of this memo; the allowable character sequences that conform to the resource rule are defined by the Resourceprep profile of [STRINGPREP] as documented in Appendix B of this memo; and the sub-domain rule makes reference to the concept of an internationalized domain label as described in [IDNA].)

jid = [ node "@" ] domain [ "/" resource ] domain = fqdn / address-literal fqdn = (sub-domain 1*("." sub-domain)) sub-domain = (internationalized domain label) address-literal = IPv4address / IPv6address

All JIDs are based on the foregoing structure. The most common use of this structure is to identify an instant messaging user, the server to which the user connects, and the user's connected resource (e.g., a specific client) in the form of . However, node types other than clients are possible; for example, a specific chat room offered by a multi-user chat service could be addressed as (where "room" is the name of the chat room and "service" is the hostname of the multi-user chat service) and a specific occupant of such a room could be addressed as (where "nick" is the occupant's room nickname). Many other JID types are possible (e.g., could be a server-side script or service).

Each allowable portion of a JID (node identifier, domain identifier, and resource identifier) MUST NOT be more than 1023 bytes in length, resulting in a maximum total size (including the '@' and '/' separators) of 3071 bytes.

一个实体可以是任何网络端点(如网络中的一个ID)并能够用XMPP通信的事物。所有这一类的实体可以唯一编址的，并符合[RFC 2396 [URI]]风格。因为历史原因，一个XMPP实体的地址被叫做Jabber标识符或JID。一个有效的JID包括三个部分：域标识符，节点标识符和资源标识符

JID语法使用[ABNF]表达式定义。(IPv4地址和IPv6地址的规则的定义在附录B [IPv6] 中

jid = [ node "@" ] domain [ "/" resource ]

domain = fqdn / address-literal

fqdn = (sub-domain 1*("." sub-domain))

sub-domain = (internationalized domain label)

address-literal = IPv4address / IPv6address

所有的JID都是基于上述结构中的。这个结构大多是用来标识一个即时消息通信的用户，在服务器上有哪几个连接，及用户的连接资源以<user@host/resource> 的形式. 可是,节点的类型可能不是客户端;例如一个聊天室提供多用户聊天服务，它的地址可以可以是<room@service>( “room”是聊天室的名字，"service"是提供多用户聊天服务的主机名) 。或者一个聊天室中的某个用户被编址为<room@service/nick> ( "mick"是该用户在聊天室中的昵称). 具有多个其它JID类型是可能的(如可以是一个服务器端的 script或服务)。

一个JID的每一部分(域标识符，节点标识符和资源标识符)的长度都不能超过1023 个字节，从而总字节数(包括"@"和"/")不能超过3071个字节。

待续......

飛雪(leo) 2006-12-31 13:05 发表评论

XMPP 协议

飛雪(leo) — Sun, 31 Dec 2006 04:54:00 GMT

XMPP 协议

XMPP 协议是在www.jabber.org上公布的，是一种标准的即时通讯协议

JEP-0078

JEP-0078: Non-SASL Authentication

SASL：Simple Authentication and Security Layer 简单的认证及加密层

1、客户端向服务器端发送XML流

xmlns='jabber:client'

xmlns:stream='http://etherx.jabber.org/streams'>

2、服务器返回消息

注意中间的ID，这个ID是服务器端返回给客户端的验证信息，验证信息一般是以该ID号+用户密码通过SHA1(RFC3174)算法进行操作的。也就是说客户端得到该ID和密码经过SHA1算法加密后返回给服务器。

3、客户端想服务器提交请求获取登录需要验证的字段

4、服务器返回登录需要验证的字段

这个digest就是上面经过SHA1算法得出的结果字段

如果客户端发送的字段包括了用户名和IQ-GET的字段，服务器不应该返回错误消息（因为需要服务器判断当前用户名是否在使用），如果服务器不支持可插入的简单认证及密码模块，那么必须返回一个的错误;如果客户端企图使用SASL认证但是失败，服务器必须返回错误信息

在认证过程中，jabber:iq:auth命名、用户名和资源是必须要求客户端提供的，而服务器返回的XML流中也必须提供和这2个元素。

5、客户端提交字段内容进行验证

文本格式，非加密模式

bill

Calli0pe

globe

加密模式

bill

48fc78be9ec8f86d8ce1c39c320c97c21d62334d

globe

6、登录结果

成功

失败 – 认证失败，可能是用户名密码不匹配或数字验证错误

失败 – 资源冲突/错误

失败 – 没有提供需要验证的字段

其他的就没什么重要的了，JEP-0078就到此了吧，剩余的重要工作就是如何配置SASL

飛雪(leo) 2006-12-31 12:54 发表评论

基于XMPP的JABBERD功能特性分析

飛雪(leo) — Sun, 31 Dec 2006 04:50:00 GMT

摘要: 基于XMPP的JABBERD功能特性分析 ... 阅读全文

飛雪(leo) 2006-12-31 12:50 发表评论