一种针对XMPP域内文件传输的出席信息负载优化方法及系统

摘要

本发明提供一种针对XMPP域内文件传输的出席信息负载优化方法及系统，该方法用于降低同一域内用户A的客户端CA跟用户B的客户端CB进行文件传输时的出席信息负载，所述方法包含：步骤1，判断要通信的两个用户的客户端是否属于同一域，如果为同一域则进入下一步骤，否则采用原有出席信息服务机制回报出席信息负载；步骤2，估算文件的传输时间；步骤3，基于文件传输时间，并假设两个正在进行域内文件传输的用户在线离线信息基本不变的前提反馈出席信息负载；其中，原有出席信息服务机制是：服务器收到对客户端的出席信息查询请求后，实时向客户端发送probe信息查询，并以查询结果应答。本发明明显的提高了网络性能，为即时通信应用的负载优化提供策略。

说明书

技术领域

本发明涉及支付结算技术，具体涉及一种针对XMPP域内文件传输的出席信息负载优化方法及系统。

背景技术

即时通信(Instant Messaging，IM)已经成为继Email和Web之后的第三大互联网应用，具有实时性、在线性与文本交互性等特征。从功能的角度讲，IETF定义了两种IM基本服务(如图1-a和图1-b所示)：即时消息服务(Instant Messaging Service)和出席服务(Presence Service)。前者用于传递消息信息，而后者用于维护出席信息。

IM通用协议主要有三个代表：IMPP(Instant Messaging and Presence Protocol)协议簇、XMPP(Extensible Messaging and Presence Protocol)协议簇以及SIMPLE(SIP forInstant Messaging and Presence Leverage Extension)协议簇。XMPP与SIMPLE都是遵循IMPP协议簇的规约而制定的，并在应用领域有完整的实现案例(如表1所示)，如IBM、微软和中国移动支持SIP/SIMPLE，而Google、惠普和Oracle等公司支持XMPP。

表1，IM典型应用与协议对应表

  IM应用  协议  MSN音视频应用、移动飞信  SIMPLE  Gtalk、新浪UC、Psi、Jive messenger  XMPP

随着互联网传输性能的改善和信号处理技术的提高，IM应用软件开始支持语音、视频和文件传输等业务。而随着业务的多媒体化，IM产生的流量也越来越大，针对IM的负载优化已经引起工业界和学术界的广泛关注。通过调研归纳，IM负载有以下两种分类方式。

从负载网络特性看，主要包括域内负载和域间负载。域内负载是两个客户端连接到同一IM服务器通信时产生的网络流量，而域间负载是两个客户端通过连接不同IM服务器通信时产生的网络流量，显然域内负载是域间负载的子集。

从负载内容特性看，主要包括即时消息负载和出席信息负载。即时消息是用户传递的交互信息，而出席信息则用于表达一个实体当前的网络可用性，包括主状态(如离线、在线等)和亚状态(如忙碌、离开等)。

在第一种分类方式中，IM服务器往往以城域网为基本单元分布，比如腾讯会在北京网通城域网布置至少一个IM服务器。而城域网是在一个城市范围内所建立的宽带局域网，具有网内传输时延较小，网络状况相对稳定的特点。由于即时消息负载占IM负载很大比例，因此目前面向即时消息的负载优化(如基于多媒体压缩的优化等)占有主导地位。然而，如果城域内几十万人同时在线使用IM，尽管单个出席信息所用字节较小，但是出席信息负载总和将是一个不容忽视的数字，将会对IM服务器造成非常大的负担。

通过以上分析，本发明专利将针对IM域内文件传输进行出席信息负载优化，具有重要的意义，需要面对两个重要挑战：

第一，IM通信协议多种多样，不同的协议提供不同的接口和功能。如XMPP中，用户A的客户端C_A与同一域内用户B的客户端C_B进行文件传输时，服务器在负责建立C_A与C_B的传输连接之后，C_A与C_B将进行P2P类型的直接传输。因此针对某种特定的协议，如何利用或扩展相关接口，获取文件传输的相关信息(如计算传输剩余时间等)，是负载优化的前提和基础。

第二，出席信息服务的相关机制比较复杂(包含初始化出席信息和出席信息广播等功能)，对每个客户端C来说，均包括出席信息主动汇报和被动汇报。主动汇报是指当C出席状态发生变化时，主动向服务器报告。而被动汇报是接受到服务器固定频率的探测后进行报告。因此，当发现C_A跟用户B的客户端C_B进行文件传输时，如何有效地改进出席信息服务的相关机制来降低出席信息负载，是亟待解决的核心问题。

在即时通信应用中，传统的出席信息服务策略缺乏对网络环境和用户当前状态信息的利用，只是单纯地接受客户端主动更新和定时对客户端出席信息状态的查询，而在即时通信如此普及的今天，大量的出席信息状态查询无疑增加了网络的流量负担。因此，在XMPP即时通信协议基础上，本发明提出了一种新的基于定时器和事件的混合Presence Probe机制。

针对以上问题，本专利首先选取XMPP协议作为IM文件传输的承载协议作为出席信息负载优化突破口。XMPP是一种基于XML(Extensible Markup Language)的开放通信标准，遵循RFC2779中定义的需求，由一组标准协议及扩展协议组成。标准XMPP协议采用C/S模式，XMPP客户端之间通过XMPP服务器交互IM信息，并可以通过网关使XMPP网络与非XMPP网络互通(系统架构如图2所示)。

发明内容

本发明的目的在于，为克服现有技术在即时通信应用中出席信息服务策略缺乏对网络环境和用户当前状态信息的利用，只是单纯地接受客户端主动更新和定时对客户端出席信息状态的查询，而在即时通信如此普及的今天，大量的出席信息状态查询无疑增加了网络的流量负担，进而大大影响影响网络的质量，从而提供一种针对XMPP域内文件传输的出席信息负载优化方法及系统。

为了实现上述目的，本发明提供一种针对XMPP域内文件传输的出席信息负载优化方法，该方法用于降低同一域内用户A的客户端C_A跟用户B的客户端C_B进行文件传输时的出席信息负载，所述方法包含：

步骤1，判断要通信的两个用户的客户端是否属于同一域，如果为同一域则进入下一步骤，否则采用原有出席信息服务机制回报出席信息负载。

步骤2，估算文件的传输时间。

步骤3，基于得到的文件传输时间，并假设两个正在进行域内文件传输的用户在线离线信息基本不变的前提反馈出席信息负载。

其中，所述原有出席信息服务机制是：服务器收到对客户端的出席信息查询请求后，实时向客户端发送probe信息查询，并以查询结果应答。

上述技术方案中，所述步骤1当发现C_A和C_B的JID的domain域相同，则表示两者处于同一IM域内。

所述步骤2通过获取待传输文件的大小并依据文件大小和采集的文件传输速度估算文件的传输时间；其中，所述估算公式为：

t₀＝size/v；

其中，v为获取的C_A和C_B间文件传输速度，size为传输文件大小。4、根据权利要求3所述的针对XMPP域内文件传输的出席信息负载优化方法，其特征在于，所述文件大小通过捕获<file/>元素中size属性的值来获取。

所述文件传输速度通过XMPP服务器向客户端C_A发送询问信息获取，其中，所述询问信息根据XML语法定义了<rate/>元素，该元素仅包含一个rate属性，且所述询问信息被包含在IQ节中进行传输。

所述步骤3进一步包含如下子步骤：

当客户端C_A和客户端C_B进行域内文件传输时，服务器开启定时器T＝t₀，在t₀时间内，若文件传输没有中断，则认为C_A和C_B的在离线状态不变，此时采用更新的出席信息服务机制；若t₀时间内文件传输出现中断，客户端负责向服务器报告文件传输中断信息，服务器会停止定时器，并恢复原有出席信息服务机制；当定时器时间到时时，域内文件传输完成，服务器同样会恢复原有出席信息服务机制；其中，更新的出席信息服务机制是：若XMPP服务器收到对C_A和C_B的出席信息查询请求，直接用服务器本地数据库中存储的文件传输前C_A和C_B的出席信息状态应答；原有出席信息服务机制是：收到对客户端的出席信息查询请求后，实时向客户端发送probe信息查询，并以查询结果应答。

基于上述方法，本发明还提供一种针对XMPP域内文件传输的出席信息负载优化系统，该系统用于降低同一域内用户A的客户端C_A跟用户B的客户端C_B进行文件传输时的出席信息负载，该系统包含：XMPP服务器、用户A的客户端C_A和用户B的客户端C_B，其特征在于，所述系统还包含：

判断模块，用于判断要通信的两个用户的客户端是否属于同一域，如果为同一域则进入下一步骤，否则采用原有出席信息服务机制回报出席信息负载。

传输时间估算模块，用于获取待传输文件的大小并依据文件大小和采集的文件传输速度得到估算的文件传输时间。和

出席信息负载反馈模块，用于基于两个正在进行域内文件传输的用户的客户端在线离线信息基本不变的前提反馈出席信息负载。

上述技术方案中，当所述判断模块发现C_A和C_B的JID的domain域相同，则表示两者处于同一IM域内。

所述传输时间估算模块进一步包含如下子模块：

获取传输文件大小子模块，该模块通过捕获<file/>元素中size属性的值，获得传输文件的大小。

字节流建立子模块，用于若经过协商C_B接受C_A传输文件请求时回送给C_A确认信息，并通知C_A建立字节流。

获取文件传输度的模块，该模块依据XMPP服务器向客户端C_A发送询问信息，获取C_A和C_B间文件传输速度；其中，所述询问信息根据XML语法定义了<rate/>元素，该元素仅包含一个rate属性，且所述询问信息被包含在IQ节中进行传输。

文件传输时间生成模块，用于依据获取的文件传输速度和文件大小估算文件传输时间。

所述文件传输时间生成模块采用下式计算文件传输时间：

t₀＝size/v；

其中，v为获取C_A和C_B间文件传输速度，size为传输文件大小。

所述出席信息负载反馈模块进一步包含如下子模块：

出席信息查询接受模块，该模块接受其他客户对C_A和C_B用户出席信息状态的查询请求，并将该请求发送判断模块进行处理；

定时器，用于依据传输时间估算模块估算的域内用户文件时间设置定时器的定时时长；

文件传输中断处理模块，用来接收文件传输中断，并将中断信息报告给服务器；

文件传输状态查询模块，该模块通过判断定时器模块中定时时间是否到时和文件传输中断模块中是否出现文件传输中断信息来判断文件传输状态；

出席信息查询应答模块，依据文件传输状态查询模块判断当前文件传输状态，若文件正在传输，该模块将直接用服务器本地数据库中存储的文件传输前C_A和C_B的出席信息状态应答；若文件传输中断或完毕，则恢复原有出席信息服务机制。

本发明的有益效果在于：本发明针对XMPP域内文件传输的P2P特性，假设两个正在进行域内文件传输的用户在线离线信息基本不变，设计了新的出席信息维护机制，从而很好的提高了网络性能，为即时通信应用的负载优化提供了一种可借鉴的技术手段。即本发明首次提出了一种新的基于定时器和事件的混合Presence Probe机制，对XMPP域内文件传输的出席信息进行负载优化，提高了网络性能为即时通信应用的负载优化提供了一种可借鉴的技术手段。

附图说明

图1-a是现有技术的一种IM服务模型示意图；

图1-b是现有技术的另一种IM服务模型示意图；

图2是现有技术的XMPP系统架构示意图；

图3是本发明提出的针对XMPP域内文件传输的负载信息维护流程图；

图4是现有技术的协商信息XMPP流中<iq/>节解析图；

图5是现有技术<iq/>节中<file/>元素解析图

图6是现有技术的字节流确认消息格式

图7是本专利所提技术的文件传输速度询问消息及应答消息格式。

具体实施方式

下面结合附图对本发明作进一步详细说明。

如图3所示，给出了在XMPP域内当客户端C_A向C_B传输文件时，一种可以降低出席信息负载的新的出席信息维护机制，主要分为以下五个步骤，详细过程解释如下：

1)C_A和C_B的域内判定

如图4所示，文件传输之前，C_A和C_B要针对传输协议、是否接受、以及网络地址和端口等信息进行协商，协商信息在XMPP流的<iq/>节中传输。如图4所示，信息中携带有C_A和C_B的JID(Jabber Identifier)，格式为nodedomain/resource。domain表示一个网关，或者是提供服务的一个子节点。node通常代表访问服务器的实体，比如即时通信客户端。resource通常代表一个特定的会话、连接、属于实体的对象。若发现C_A和C_B的JID的domain域相同，则表示两者处于同一IM域内。

2)传输文件大小和传输时间估算

如图5所示，C_A和C_B针对传输协议协商完毕以后，还要对文件相关信息进行协商(如文件名称、大小、最新修改日期等)，从而确定C_B是否接受文件。协商信息包含在<iq/>节的<file/>元素中。我们通过捕获<file/>元素中size属性的值，可以获得传输文件的大小。

如图6所示，若经过协商，C_B接受C_A传输文件请求，会回送给C_A确认信息，并通知C_A建立字节流。

如图7所示，为了获取C_A和C_B间文件传输速度，XMPP服务器会向客户端C_A发送询问信息。为此，我们根据XML语法定义了<rate/>元素，其中只包含一个rate属性。询问信息也被包含在IQ节中传输。

XMPP服务器可以通过文件大小size和文件传输速度v来估算文件传输时间t₀＝size/v。另外，由于在P2P传输中文件传输速度是刚开始缓慢后来逐渐加快的，所以我们获取的v值比平均值稍小，故估算出的是文件传输时间的最大值。

3)基于定时器和事件的混合Presence Probe机制

C_A和C_B完成字节流协商后开始传输文件。根据前面所作的假设，当两个客户端C_A和C_B在IM域内进行文件传输时，我们可以认为其在线离线信息基本不变。此时，服务器开启定时器T＝t₀，在t₀时间内，若文件传输没有中断，则认为C_A和C_B的在离线状态不变。此时若XMPP服务器收到对C_A和C_B的出席信息查询请求，可以直接用服务器本地数据库中存储的文件传输前C_A和C_B的出席信息状态应答。若文件传输出现中断，客户端负责向服务器报告文件传输中断信息，服务器会停止定时器，并恢复原有出席信息服务机制(收到对客户端的出席信息查询请求后，实时向客户端发送probe信息查询)。当定时器时间到时时，我们认为域内文件传输完成，服务器同样会恢复原有出席信息服务机制。

表2，C_A或C_B出席信息查询应答策略表

最后应说明，此处所描述的实例仅用于解释本发明，本发明并不限定具体业务类别、用户终端类别以及支付系统类别，对以上内容所做的变换也落在本发明的保护范围之内。