XMPP协议之XML流
2006-10-10 10:01
169 查看
XMPP通过TCP传什么了(XML流)?
传输的是与即时通讯相关的指令。在以前这些命令要么用2进制的形式发送(比如QQ),要么用纯文本指令加空格加参数加换行苻的方式发送(比如MSN)。而XMPP传输的即时通讯指令的逻辑与以往相仿,只是协议的形式变成了XML格式的纯文本。这不但使得解析容易了,人也容易阅读了,方便了开发和查错。而XMPP的核心部分就是一个在网络上分片断发送XML的流协议。这个流协议是XMPP的即时通讯指令的传递基础,也是一个非常重要的可以被进一步利用的网络基础协议。所以可以说,XMPP用TCP传的是XML流。
举个例子看看所谓的XML流是什么样子的?
客户端:<?xml version='1.0'?>
<stream:stream
to='example.com'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
服务器:<?xml version='1.0'?>
<stream:stream
from='example.com'
id='someid'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
...其他通信...
客户端:<message from='juliet@example.com'
to='romeo@example.net'
xml:lang='en'>
客户端: <body>Art thou not Romeo, and a Montague?</body>
客户端:</message>
服务器:<message from='romeo@example.net'
to='juliet@example.com'
xml:lang='en'>
服务器:<body>Neither, fair saint, if either thee dislike.</body>
服务器:</message>
客户端:</stream:stream>
服务器:</stream:stream>
以文档的观点来看,客户端或服务器发送的所有XML文本连缀在一起,从<stream>到</stream>构成了一个完整的XML文档。其中的stream标签就是所谓的XML Stream。在<stream>与</stream>中间的那些<message>...</message>这样的XML元素就是所谓的XML Stanza(XML节)。XMPP核心协议通信的基本模式就是先建立一个stream,然后协商一堆安全之类的东西,中间通信过程就是客户端发送XML Stanza,一个接一个的。服务器根据客户端发送的信息以及程序的逻辑,发送XML Stanza给客户端。但是这个过程并不是一问一答的,任何时候都有可能从一个方发信给另外一方。通信的最后阶段是</stream>关闭流,关闭TCP/IP连接。
XML节
XML节通过XML流来发送,XMPP定义了三种顶级XML节
<iq />
<message />
<presence />
XMPP给这三种节定义了五种通用属性
to
from
id
type
xml:lang
to属性指定接收节的JID。
from属性指定发送者的JID。
id属性是可选的。并且,在接收应用(通常是一个服务器)中是唯一的。注意:流ID可能是严格安全的,并且因此必须是即不能预测也不能重复的
type属性指定目的或消息上下文,出席或IQ节的详细信息。iq节的type属性有:Error,Get,Result,Set; presence节的type属性有:Available,Subscribe,Subscribed,Unsubscribe, Unsubscribed,Unavailable,Probe,Error,Invisible; message节的type属性有:Chat,Error,GroupChat,Headline,Normal
xml:lang属性值指定任意可读XML字符数据的缺省语言
<message />节定义了消息语义,<message />节可被看作“推”机制,一个实体推信息给其它实体,与EMAIL系统中发生的通信类似。所有消息节应该拥有‘to’属性,指定有意的消息接收者;根据接收到那样的一个节,服务器应该路由或传送它到有意的接收者。
<presence />节定义了出席语义,<presence />节可被看作基本广播或“出版-订阅”机制,多实体收到他们已订阅(在这种情况下,网络可利用信息)实体的信息。总的来说,出版实体应该发送一个不带‘to’属性的出席节,在这种情况下,与此实体相连的服务器应该广播给所有订阅实体。然而,一个出版实体也可能发送一个带有‘to’属性的出席节,此种情况下,服务器应该路由或传送节到有意的接收者。
<iq />节定义了请求语义,<iq />节可被看作一个请求-响应机制,与[HTTP]在某些方面相似。IQ语义让一个实体向其它实体请求或接收其它实体的响应成为可能。请求与响应的数据内容由IQ无素的直接子元素的命名空间声明定义,并且,交互由请求实体通过使用‘id’属性来跟踪。因此,IQ交互遵从结构化数据交换的一个通用模式,此交换例如得到/结果或设置/结果(虽然如果合适的话,对一个请求的响应可能会以错误返回)。
传输的是与即时通讯相关的指令。在以前这些命令要么用2进制的形式发送(比如QQ),要么用纯文本指令加空格加参数加换行苻的方式发送(比如MSN)。而XMPP传输的即时通讯指令的逻辑与以往相仿,只是协议的形式变成了XML格式的纯文本。这不但使得解析容易了,人也容易阅读了,方便了开发和查错。而XMPP的核心部分就是一个在网络上分片断发送XML的流协议。这个流协议是XMPP的即时通讯指令的传递基础,也是一个非常重要的可以被进一步利用的网络基础协议。所以可以说,XMPP用TCP传的是XML流。
举个例子看看所谓的XML流是什么样子的?
客户端:<?xml version='1.0'?>
<stream:stream
to='example.com'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
服务器:<?xml version='1.0'?>
<stream:stream
from='example.com'
id='someid'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
...其他通信...
客户端:<message from='juliet@example.com'
to='romeo@example.net'
xml:lang='en'>
客户端: <body>Art thou not Romeo, and a Montague?</body>
客户端:</message>
服务器:<message from='romeo@example.net'
to='juliet@example.com'
xml:lang='en'>
服务器:<body>Neither, fair saint, if either thee dislike.</body>
服务器:</message>
客户端:</stream:stream>
服务器:</stream:stream>
以文档的观点来看,客户端或服务器发送的所有XML文本连缀在一起,从<stream>到</stream>构成了一个完整的XML文档。其中的stream标签就是所谓的XML Stream。在<stream>与</stream>中间的那些<message>...</message>这样的XML元素就是所谓的XML Stanza(XML节)。XMPP核心协议通信的基本模式就是先建立一个stream,然后协商一堆安全之类的东西,中间通信过程就是客户端发送XML Stanza,一个接一个的。服务器根据客户端发送的信息以及程序的逻辑,发送XML Stanza给客户端。但是这个过程并不是一问一答的,任何时候都有可能从一个方发信给另外一方。通信的最后阶段是</stream>关闭流,关闭TCP/IP连接。
XML节
XML节通过XML流来发送,XMPP定义了三种顶级XML节
<iq />
<message />
<presence />
XMPP给这三种节定义了五种通用属性
to
from
id
type
xml:lang
to属性指定接收节的JID。
from属性指定发送者的JID。
id属性是可选的。并且,在接收应用(通常是一个服务器)中是唯一的。注意:流ID可能是严格安全的,并且因此必须是即不能预测也不能重复的
type属性指定目的或消息上下文,出席或IQ节的详细信息。iq节的type属性有:Error,Get,Result,Set; presence节的type属性有:Available,Subscribe,Subscribed,Unsubscribe, Unsubscribed,Unavailable,Probe,Error,Invisible; message节的type属性有:Chat,Error,GroupChat,Headline,Normal
xml:lang属性值指定任意可读XML字符数据的缺省语言
<message />节定义了消息语义,<message />节可被看作“推”机制,一个实体推信息给其它实体,与EMAIL系统中发生的通信类似。所有消息节应该拥有‘to’属性,指定有意的消息接收者;根据接收到那样的一个节,服务器应该路由或传送它到有意的接收者。
<presence />节定义了出席语义,<presence />节可被看作基本广播或“出版-订阅”机制,多实体收到他们已订阅(在这种情况下,网络可利用信息)实体的信息。总的来说,出版实体应该发送一个不带‘to’属性的出席节,在这种情况下,与此实体相连的服务器应该广播给所有订阅实体。然而,一个出版实体也可能发送一个带有‘to’属性的出席节,此种情况下,服务器应该路由或传送节到有意的接收者。
<iq />节定义了请求语义,<iq />节可被看作一个请求-响应机制,与[HTTP]在某些方面相似。IQ语义让一个实体向其它实体请求或接收其它实体的响应成为可能。请求与响应的数据内容由IQ无素的直接子元素的命名空间声明定义,并且,交互由请求实体通过使用‘id’属性来跟踪。因此,IQ交互遵从结构化数据交换的一个通用模式,此交换例如得到/结果或设置/结果(虽然如果合适的话,对一个请求的响应可能会以错误返回)。
相关文章推荐
- XMPP协议的原理介绍
- XMPP协议的原理介绍
- XMPP协议之Androidpn介绍
- XMPP协议之Openfire 集群配置
- XMPP协议分析—具体篇
- XMPP协议学习笔记一
- XMPP协议的学习总结(1)
- XMPP协议的原理介绍
- XMPP协议的原理介绍(转载)
- XMPP协议分析-原理篇
- XMPP核心协议客户端
- XMPP协议分析-原理篇
- RFC3920——可扩展的消息和出席信息协议 (XMPP): 核心协议
- 关于xmpp协议的即时通讯分析
- XMPP RFCs 1.0基本协议
- XMPP协议的原理介绍
- .net平台 基于 XMPP协议的即时消息服务端简单实现
- Android基于XMPP协议之实现即时通讯的原理
- .net平台 基于 XMPP协议的即时消息服务端简单实现
- IM设计思考:XMPP多用户文本聊天协议(MUC:Multi User Chat)