现在的位置: 首页 > 综合 > 正文

IM设计思考:XMPP消息格式

2018年03月30日 ⁄ 综合 ⁄ 共 1778字 ⁄ 字号 评论关闭

交换消息是XMPP的一个基本用途并且随之而来的是一个用户生成一个发给另一个实体的消息节。

XMPP定义的消息节语法完整格式如下:

<message
    from='juliet@example.com/balcony'
    to='romeo@example.net'
    type='chat'
    xml:lang='en'>
  <subject>I implore you!</subject>
  <subject xml:lang='cs'>
    Úpěnlivě prosím!
  </subject>
  <body>Wherefore art thou, Romeo?</body>
  <body xml:lang='cs'>
     Pročež jsi ty, Romeo?
  </body>
  <thread parent='e0ffe42b28561960c6b12b944a092794b9683a38'>
    0e3141cd80894871a68e6fe6b1ec56fa
  </thread>
</message>

from属性:设置消息发送方自身的Full JID(node@domain/resource)

to属性:     设置消息接收方的Bare JID(node@domain),通常第一次发送方无法确知接收方的Full JID,通过服务器中转路由时由服务器根据Base JID映射接收方的Full JID。

                     但如果这个消息是在回复之前接收到的消息,则to属性应该包含对方完整的Full JID。

                     如此设计的好处在于:当to属性设定为Full JID时可以帮助服务器省却了接收者资源定位(接入定位),在一个IM服务集群环境中这种定位通常意味着一次

                     分布式缓存读取操作。

type属性:XMPP约定了type的枚举值,包括:

                      chat:            表明在一个点对点会话环境中的聊天消息。

                      groupchat:表明在一个多人会话环境中的聊天消息。

                      headline:    通常一些系统通知、警告、实时数据更新采用此类型,这类消息不期待客户端回复或响应,具有很高的实时性,不需要离线存储。

                      normal:       默认的消息类型(缺乏type属性时),通常表达一种要求接收方必须确认的消息,一般用于系统提示强制用户确认或取消等。

                      error:           表示一个错误消息,可能由服务端发送给客户端,也可能是另一个客户接收端回应给客户发送端,此类消息也不需要离线存储。

<subject>子元素:表明一个消息主题,通常客户端实现显示在聊天窗口标题栏处

<body>子元素:    消息内容部分

<subject>和<subject>都允许包含多个元素标签,不同的标签根据xml:lang表达了不同的语言(XMPP可是一个国际化协议)

<thread>子元素:用于跟踪一个会话, 该元素的作用主要在于方便客户端实现消息展示(例如:消息历史查询时按每次会话折叠显示消息),每次会话产生一个唯一的thread id,xmpp推荐采用uuid算法,具体用法可参考XEP-0201扩展协议和RFC6121。


还有一种情况是离线消息,它与正常消息的格式和处理机制又有所不同,格式如下所示:

<message from='romeo@montague.net/orchard' to='juliet@capulet.com'>
  <body>
    O blessed, blessed night! I am afeard.
    Being in night, all this is but a dream,
    Too flattering-sweet to be substantial.
  </body>
  <delay xmlns='urn:xmpp:delay'
     from='capulet.com' 
     stamp='2002-09-10T23:08:25Z'>Offline Storage</delay>
</message>


离线消息中包含了一个<delay>的子元素,<delay>子元素的from记录了延迟消息的最后来源方,如上例中from为capulet.com指接收离线消息人连接的服务器,离线消息最终由该服务器发出

stamp属性记录了离线消息的存储时间,客户端实现应显示该时间而非接收到的时间。



抱歉!评论已关闭.