CN101378544B - 信息轮询方法、装置及其系统 - Google Patents

Abstract

本发明提供一种信息轮询方法、装置及其系统，其中消息网关接收来自应用客户端中的应用的信息轮询请求，根据所述信息轮询请求，消息网关获取所述应用所请求的消息，并计算所述应用的参考轮询周期，最后将获取的所述应用所请求的消息和所述参考轮询周期发送给所述应用。所述应用根据所接收到的参考轮询周期以及应用客户端的负载状况而确定下一次轮询周期。根据本发明，提高了消息轮询的效率和质量，同时也保证了系统的正常运行，减少在现有状况中可能出现的消息拥堵和系统崩溃的情况。

Description

信息轮询方法、装置及其系统

技术领域

本发明总体上涉及一种信息轮询方法和装置，特别地，涉及一种自适应地动态调整轮询周期的信息轮询的方法、装置及其系统。

背景技术

现在消息网关作为一种中间媒介装置，被普遍用于电信增值应用向移动通讯网络发送消息和从移动通讯网络接收消息。典型的例子比如处理短消息或多媒体消息的短消息网关、多媒体彩信中心以及Parlay X网关。如图1所示，终端用户可以通过他的手持终端10向所述电信增值应用13发送短消息或者多媒体消息请求相关服务，比如终端用户可以请求下载一个手机铃声。终端用户所发送的消息会被消息网关12截获，然后再由所述消息网关12发送到该消息所指定的地址，从而所述电信增值应用13能够获得终端用户所发送的该消息。

目前电信增值应用有两种方式从网关中获得信息：推方式15和轮询方式16。在推方式15中，消息网关12一旦从通讯网络11中获得消息，所述消息网关立即将该消息发送到相应的应用13。而在轮询方式16中，所述应用13定期向消息网关12请求到达的消息。

一般而言，当消息量比较大时，轮询方式比推方式更为有效，因为应用可以通过一个消息请求动作而获得一组消息。相反，对于推方式，消息网关一次只能向应用推一个消息，这样将带来大量的交互负担。

对于那些只是从网络中获取消息的简单应用，比如对移动用户的短信电视答题的应用，轮询方式的优越性更为明显。相对于消息网关，所述应用处于应用客户端14中，当所述应用需要相关消息时，其主动向消息网关请求有关消息。然而对于推方式而言，所述应用只能被动地接收消息网关所发送来的消息，这使得所述应用必须保持在线状态，而且这也会带来其它更多繁重而复杂的消息接收工作。

在轮询方式中，如何确定合适的轮询周期是一个重要的问题。因为太短的轮询周期会使消息网关的工作负载过于繁重，而太长的轮询周期则会导致过多的消息在等待处理。因此如何通过更好地确定轮询周期，从而提高消息网关的效率和服务质量，变得十分重要。

目前通常的方法是管理者根据自身的经验设定轮询周期，而不考虑消息网关的目前运行状况。而当对于所述应用没有很多相应的消息时，这种通常的简单周期性地轮询消息网关的方法将会给消息网关带来不必要的负担。

类似地，对于消息网关之外的其他许多信息设备，同样存在信息轮询中的效率问题。上面只是以消息网关为例来说明现有技术面临的问题，只是因为消息网关中的消息轮询的周期问题尤为迫切。本发明将提供的方法、设备及其系统并不局限于消息网关及其相关方法。

发明内容

鉴于上述问题，需要提高消息轮询的效率。

为了解决现有技术中存在的问题，根据本发明的第一方面，提供一种信息轮询方法，所述方法包括如下步骤：接收来自应用客户端中的应用的信息轮询请求；获取所述应用所请求的消息，并计算所述应用的参考轮询周期；将获取的所述应用所请求的消息和所述参考轮询周期发送给所述应用。

根据本发明的另一方面，本发明还提供一种用于信息轮询的装置，所述装置包括：接收发送装置，所述接收发送装置接收来自应用客户端中的应用的信息轮询请求；调度装置，所述调度装置计算出所述应用的参考轮询周期，由所述接收发送装置将所述参考轮询周期发送给所述应用。

根据本发明的另一方面，本发明还提供一种信息轮询系统，所述系统包括：消息网关，其中，所述消息网关接收运行在应用客户端中的应用所发送的信息轮询请求，响应于接收到的所述信息轮询请求，所述消息网关获取所述应用所请求的消息，并计算出所述应用的参考轮询周期，将获取的所述应用所请求的消息和所述参考轮询周期发送给所述应用客户端中的应用。

通过本发明的上述技术方案，实际的轮询周期可以动态地被调整。当消息到达的速率较慢时，轮询周期会根据减少的服务器负载而延长，而当消息到达的速率较高时，轮询周期将被缩短以提供更好的响应能力。

另一方面，当消息网关的负载过高时，还可以动态地延长轮询周期，从而可以保护消息网关，避免过载。且通过对更重要的应用提供较短的轮询周期，电信运营商就可以对不同应用提供不同级别的服务。

结合附图阅读本发明实施方式的详细描述后，本发明的其它特点和优点将变得更加清楚。

附图说明

为了对本发明实施例的特征和优点进行详细说明，将参照以下附图。如果可能的话，在附图和描述中使用相同或者类似的参考标号以指代相同或者类似的部分。其中：

图1示出了现有技术中获取消息的推方式和轮询方式；

图2示出了本发明的信息轮询方法的第一实施方式的各个步骤；

图3示出了本发明的第一实施方式的信息交互过程；

图4示出了本发明的第二实施方式的信息轮询方法的各个步骤；

图5示出了本发明第二实施方式的系统框图；

图6示出了本发明第三实施方式的信息轮询方法的各个步骤；

图7是计算参考轮询周期方法的示意图。

具体实施方式

以下根据附图详细说明本发明的实施例。这些附图形成说明书的一部分且其例示了本发明的几个实施方式。可以理解，还可以使用其他实施方式，且可作出结构上和操作上的变换，而不脱离本发明的范围。另外上述实施方式仅用于说明本发明是如何实现的，而不能理解为对本发明的保护范围的限制。

图2示出了根据本发明一个实施例的消息轮询方法的各个步骤的，而图3则示出了本发明上述实施例的信息交互过程。下面结合图2及图3详细介绍本发明的第一实施例。

首先在步骤211中，处于应用客户端14的应用313采用轮询的方式，主动向消息网关312发送轮询请求，消息网关312接收应用313发送的轮询请求。一方面，消息网关312会获取应用313此次轮询请求所需要的消息。另一方面，消息网关312还会向消息网关中的调度装置314发送计算参考轮询周期的请求，调度装置314计算参考轮询周期，具体计算参考轮询周期的方法将会在说明书的后面部分进行详细说明。调度装置314将计算好的参考轮询周期返回到消息网关312，最后消息网关312将获取到的此次轮询请求所需要的消息和上述计算好的参考轮询周期发送给应用313，如此则完成了一次轮询320。与前次轮询320一样，在下一次轮询322中，应用313还会获得一个重新计算的参考轮询周期。作为优选，应用313可以根据参考轮询周期或者其所在的应用客户端的负载情况而决定下一次消息轮询322的时间周期，即应用313所获得的参考轮询周期仅供其参考，当应用313所处的应用客户端的负载过于繁重时，应用313可以重新设定其轮询周期。另外作为优选，应用可以根据相关紧急请求，立即发送对特定消息的轮询请求，而不考虑所接收到的参考轮询周期。

图4示出了根据本发明另外一个更为优选的第二实施例的消息轮询方法的各个步骤的流程图，图5则示出了本发明为设施上述更为优选实施例的相关装置及其系统框图。下面结合图4及图5详细介绍本发明作为优选的第二实施方式。

众所周知，每一个应用客户端14可以包括有一个或多个的应用513。通过手持通讯设备510和移动通讯网络511，用户可以将相关消息或者服务请求发送到消息网关512中，所述消息或者服务请求被存储在消息网关的消息队列524中，当然也可以存储在数据库中或者采取其它合适的存储方式。其中在步骤410中，位于应用客户端14的应用513采用轮询的方式，通过应用客户端14的应用客户端输入输出端口531主动向消息网关512发送轮询请求，消息网关512通过网关输入输出端口526接收到应用513发送的轮询请求，并对轮询请求进行处理。一方面，消息网关512会根据轮询请求从指定消息队列524中读取应用513此次轮询请求所需要的消息，同时将这些消息从该消息队列中删除。另一方面，消息网关512还会指定调度装置525计算参考轮询周期。调度装置525将从消息队列524中获得等待消息队列长度信息、消息到达的速率信息以及消息有效期限，其中消息队列的长度可以通过统计队列中消息的个数获得，消息到达速率可以通过在每个消息到达时实时计算获得，消息有效期限是根据具体应用所要求的服务质量(QoS)所确定。另外调度装置525还从系统控制器522获得的消息网关512的CPU负载状况，CPU负载状况可以通过现有的应用工具获取，比如利用Windows操作系统中的system monitor、Linux操作系统中的vmstat等，并从系统配置器523中获得的响应应用客户端的消息轮询请求的优先次序，该优先次序可以通过系统配置器523进行预设。然后调度装置525根据上述因素中至少之一，确定参考轮询周期，具体计算参考轮询周期的方法将会在随后进行详细说明。最后消息网关512通过网关输入输出端口526，将获取到的此次轮询请求所需要的消息和上述参考轮询周期发送给应用513，而应用513则通过应用客户端输入输出端口531接收此次轮询请求所需要的消息和上述参考轮询周期。上述参考轮询周期将由决策装置542对轮询时钟532进行设置，如此则完成了此次轮询，并确定了应用513下次轮询的轮询周期。而在根据上述参考轮询周期触发的下一次的信息轮询过程中，应用513无疑将会获得重新计算的参考轮询周期。另外作为优选，应用可以根据相关紧急请求，立即发送对特定消息的轮询请求，而不考虑所接收到的参考轮询周期。

其中上述应用513可以采用现有技术中的多种标准协议来与消息网关512进行信息交互。比如采用SMPP(short message peer-to-peerprotocol)标准协议来进行短消息的轮询，或者采用MM7(MultimediaMessaging Services protocol)标准协议来进行多媒体消息的轮询，或者：CMPP(China Mobile Peer to Peer)协议，Parlay X的短信和彩信接口等其他协议)。上述标准协议都有用于扩展目的的预留可选参数。比如，在SMPP标准协议中，预留可选参数附着在消息头和强制参数之后，可选参数可以编码成<标签，长度，值>的三参数形式。上述参考轮询周期可以通过上述用于扩展目的的预留可选参数进行传送。已有的应用可以忽略任何其不能识别的可选参数，而新的应用支持新的扩展参数就可以相应地利用这些特性。上述参考轮询周期就可以通过上述预留可选参数由消息网关送达应用。

图6示出了根据本发明另外一个更为优选的实施例的消息轮询方法。在该方法中，应用513从消息网关512中获得了所请求的消息，另外也获得了合理的参考轮询周期，一方面，应用513可以根据所获得的上述参考轮询周期而直接设置其轮询时钟，当轮询时间到达时，应用513将会向消息网关512发送下一轮的轮询请求。作为优选，应用513可以灵活处理所获得的参考轮询周期。在图6所示的步骤611中，应用513接收到消息和参考轮询周期。接收到参考轮询周期后，在步骤613中，应用513的决策装置542将根据应用客户端的负载情况进行判断。如果系统忙，则不适合按照参考轮询周期进行轮询，在步骤615中，应用513的决策装置542会根据应用系统的状况重新计算一个合适的轮询周期以替换参考轮询周期。如何根据应用系统的状况具体重新计算轮询周期的方法将会在随后进行详细说明。在步骤617中，应用513的决策装置542会根据参考轮询周期或者用于替换参考轮询周期而重新计算的轮询周期，对应用513的轮询时钟532进行设置，从而决定下一次信息轮询的时间。另外作为优选，应用可以根据相关紧急请求，立即发送对特定消息的轮询请求，而不再考虑所接收到的参考轮询周期以及用于替换参考周期的重新计算的轮询周期。

在本节中将详细讨论调度装置525根据相关信息如何计算参考周期的方法。正如前文所述，调度装置525将从消息队列524中获得的等待消息队列长度信息、消息到达的速率信息以及消息有效期限。参考图7，消息队列524具有队列长度L，并且队列中的每一个消息j都会包含有该消息的有效期限T_j-DL，即该消息要求不得迟于时间点T_j-DL得到处理，有效期限T_j-DL是达到一定服务质量(QoS)必需的一个参数。在时间轴730上，可以根据公式(1)计算时间段T_AB之间的消息到达速率r_AB。一般相信，在相邻的时间间隔内，消息到达速率基本保持平稳，因此在下面的计算中可以用T_AB时间间隔的消息到达速率r_AB来作为时间段T_BC段内的可能到达速率r_BC。其中N_AB表示在时间段T_AB内消息网关所接收到用户所发送的消息的数量。计算参考周期T的问题就是如何确定应用发送下一次轮询的合理时间间隔(或周期)T。

$r_{\mathrm{AB}}=\frac{N_{\mathrm{AB}}}{T_{\mathrm{AB}}}---\left(1\right)$

另外参数Ai用于表示应用513所处的应用客户端的处理能力，比如，在一个正常的CPU负载情况下每秒所能处理的信息条数(TPS，transaction per second)。该参数通过先期对相同的负载进行压力测试获得，并将该参数预设在消息网关中，以用于调度装置525计算参考轮询周期值T。可以考虑对参考轮询周期T施加三个约束条件，但是这三个约束条件并非必然需要同时施加，也可以施加其中之一，或根据实际情况的需要，而施加其它约束：

(1)在下一次轮询前，应用513将可以在参考轮询周期T内处理完消息网关中已经存在的和新到达的消息；

(2)消息网关中已经存在的和新到达的消息小于应用513所能处理消息数量的最大值M；

(3)在每个消息要求处理的处理期限前完成该消息的处理。

则如图7所示，可以将参考轮询周期T(从时间点B到时间点C处的时间跨度)的上述约束用公式(2)、(3)、(4)表示。

$\frac{r_{\mathrm{AB}}T+L}{A_i}<T---\left(2\right)$

r_ABT+L＜M               (3)

T＜min(T_j-DL-T_B)＝T₄    (4)

其中T_B表示时间点B的时间，而其它符号的物理含义已在上面进行了详细的说明，在此不再赘述。对式(2)、(3)作不等式变换，可以得到式(5)、(6)：

$T>\frac{L}{A_i-r_{\mathrm{AB}}}=T_1---\left(5\right)$

$T<\frac{M-L}{r_{\mathrm{AB}}}=T_3---\left(6\right)$

令T₂＝min(T₃，T₄)，符号T₁、T₂、T₃、T₄用于方便表达其对应的算式。

则参考轮询周期T可以由式(7)来计算：

T＝T₁+αβ(T₂-T₁)      (7)

其中α，β∈(0，1)，α表示应用513的优先级别。级别越高，越需要优先处理的应用，α值就越低，例如可以用α＝0.1表示级别最高的应用，而用α＝1表示最不优先的应用。这样区别可以对不同的应用给予不同的参考轮询周期，从而得到不同的服务质量。β则是用于表征消息网关512的CPU负载的一个参数。当CPU负载越重，β值就越大，相反就越小，例如可以用β＝0.1表示CPU处于最空闲的状况，β＝1表示CPU处于负载最繁重的状态。

由公式(7)计算得到的参考轮询周期T是综合考虑了等待消息队列的长度、消息到达的速率、用于处理消息轮询请求的服务器的负载状况、响应应用客户端的消息轮询请求的优先次序、消息服务期限等因素的一种优选方式之一。而事实上，本领域技术人员可以根据本发明作出各种其它实施方式，包括上述因素的任意合理的组合。比如只是考虑上述因素中的一个或者多个，就可以由式(8)、(9)或者(10)分别获得合理的参考轮询周期T：

T＝T₁+β(T₂-T₁)      (8)

T＝T₁+α(T₂-T₁)      (9)

T＝kT₂               (10)

其中加权系数k∈(0，1)。

作为优选，在应用客户端14的应用513的决策装置542在获得参考轮询周期T后，可以根据应用客户端的CPU的忙/闲状况，而决定最终采用的轮询周期T_C，公式(11)示出了T_C的计算方法：

T_C＝(1+(β₁-β₀))*T    (11)

其中β₀表示应用客户端的CPU的标准负载情况，比如可以取70％，而β₁则表示目前应用客户端的CPU的实际负载情况，当β₁小于70％时，则可以相应提前进行轮询，相反，当应用客户端负载过于繁重时，则应该延长轮询周期，以避免导致应用客户端因为负载过重而崩溃。而事实上，本领域技术人员可以根据本发明作出各种其它实施方式。比如可以用公式(12)、(13)来计算最终采用的轮询周期T_C：

T_C＝(1+δ(β₁-β₀))*T    (12)

由公式(12)、(13)计算的轮询周期T_C一个明显的好处在于不会因为应用客户端的空闲而导致过于频繁的轮询而最终过分增加消息网关的负担。

根据以上各个具体实施方式的说明可知，通过本发明的上述技术方案，实际的轮询周期可以动态地调整。当消息到达的速率较慢时，轮询周期会根据减少的消息网关的服务器负载而延长轮询周期，而当消息到达的速率较高时，轮询周期将被缩短以调高轮询频率，从而提高更好的响应能力。另一方面，消息网关的负载过高时，还可以动态地限制轮询频率，从而可以保护消息网关，避免过载。且通过对更重要的应用提供更高轮询频率，电信运营商就可以对不同应用提供不同级别的服务。另外还对于应用客户端自身的负载状况也进行动态地响应，并对轮询周期进行动态调整从而可以保证应用的自身正常运行。由此可见本发明的各个实施方式都大大提高了消息轮询的效率和质量，同时也保证了系统的正常运行，避免了在现有状况中经常出现的消息拥堵和系统崩溃的情况。

如本领域的普通技术人员所能理解的，本发明的方法和装置的全部或者任何步骤或者部件，可以在任何计算设备(包括处理器、存储介质等)或者计算设备的网络中，以硬件、固件、软件或者它们的组合加以实现，这是本领域普通技术人员在了解本发明的内容的情况下运用他们的基本编程技能和硬件设计能力就能实现的，因此不需在此具体说明。

此外，显而易见的是，在上面的说明中涉及到可能的外部操作的时候，无疑要使用与任何计算设备相连的任何显示设备和任何输入设备、相应的接口和控制程序。总而言之，计算机、计算机系统或者计算机网络中的相关硬件、软件和实现本发明的前述方法中的各种操作的硬件、固件、软件或者它们的组合，即构成本发明的设备及其各组成部件。

因此，基于上述理解，本发明的目的还可以通过在任何信息处理设备上运行一个程序或者一组程序来实现。所述信息处理设备可以是公知的通用设备。因此，本发明的目的也可以仅仅通过提供包含实现所述方法或者设备的程序代码的程序产品来实现。也就是说，这样的程序产品也构成本发明，并且存储有这样的程序产品的存储介质也构成本发明。显然，所述存储介质可以是本领域技术人员已知的，或者将来所开发出来的任何类型的存储介质，因此也没有必要在此对各种存储介质一一列举。

在本发明的设备和方法中，显然，各部件或各步骤是可以分解和/或重新组合的。这些分解和/或重新组合应视为本发明的等效方案。

以上结合本发明的优选实施方式对本发明进行了详细说明。本领域的普通技术人员知道，本发明不限于这里所图示和描述的细节，而可以在不脱离本发明的实质范围的前提下作出各种改进和修改，这些改进和修改都在本发明的保护范围之内。

尤其是，对于本领域普通技术人员来说显而易见的是，本发明不仅可应用于消息轮询应用，事实上，任何信息系统的轮询，都可以采用本方法以及相应的设备。

Claims (19)

1.一种信息轮询方法，所述方法包括如下步骤：

(a)接收来自应用客户端中的应用的信息轮询请求；

(b)获取所述应用所请求的消息，并计算所述应用的参考轮询周期；

(c)将获取的所述应用所请求的消息和所述参考轮询周期发送给所述应用，使得所述应用能够根据所述参考轮询周期确定发送下一次信息轮询请求的轮询周期，

其中，根据所述应用的新的所述信息轮询请求，循环执行步骤(a)-(c)。

2.一种如权利要求1所述的方法，其中，从消息队列中获取所述应用所请求的消息。

3.一种如权利要求1-2中任一项所述的方法，其中，计算所述参考轮询周期考虑以下因素中的至少一个：

消息队列的长度；

消息到达的速率；

用于处理信息轮询请求的服务器的负载状况；

响应应用客户端的信息轮询请求的优先次序；

应用客户端的信息处理能力；

消息有效期限。

4.一种如权利要求1-2中任一项所述的方法，其中，所述参考轮询周期被所述应用用于重新设定该应用的轮询时钟。

5.一种如权利要求4所述的方法，所述应用根据重新设定的轮询时钟发送下一次信息轮询请求。

6.一种如权利要求1-2中任一项所述的方法，所述应用根据应用客户端的负载情况以及接收到的参考轮询周期，确定发送下一次信息轮询请求的轮询周期。

7.一种如权利要求6所述的方法，所述确定的发送下一次信息轮询请求的轮询周期大于所述参考轮询周期。

8.一种如权利要求1-2中任一项所述的方法，其中所述应用根据相关紧急请求，立即发送对特定消息的轮询请求。

9.一种用于信息轮询的装置，所述装置包括：

接收发送装置，所述接收发送装置接收来自应用客户端中的应用的信息轮询请求；

调度装置，所述调度装置计算出所述应用的参考轮询周期，由所述接收发送装置将所述参考轮询周期发送给所述应用，使得所述应用能够根据所述参考轮询周期确定发送下一次信息轮询请求的轮询周期。

10.一种如权利要求9所述的用于信息轮询的装置，其中，所述装置从消息队列中获取所述应用所请求的消息。

11.一种如权利要求9至10中任一项所述的装置，其中，计算所述参考轮询周期考虑以下因素中的至少一个：

消息队列的长度；

消息到达的速率；

用于处理信息轮询请求的服务器的负载状况；

响应应用客户端的信息轮询请求的优先次序；

客户端的信息处理能力；

消息有效期限。

12.一种信息轮询系统，所述系统包括：

消息网关，其中，所述消息网关接收运行在应用客户端中的应用所发送的信息轮询请求，响应于接收到的所述信息轮询请求，所述消息网关获取所述应用所请求的消息，并计算出所述应用的参考轮询周期，将获取的所述应用所请求的消息和所述参考轮询周期发送给所述应用客户端中的应用，使得所述应用能够根据所述参考轮询周期确定发送下一次信息轮询请求的轮询周期。

13.一种如权利要求12所述的系统，其中，所述消息网关从消息队列中获取所述应用所请求的消息。

14.一种如权利要求12至13中任一项所述的系统，其中，计算所述参考轮询周期考虑以下因素中的至少一个：

消息队列的长度；

消息到达的速率；

用于处理信息轮询请求的服务器的负载状况；

响应应用客户端的信息轮询请求的优先次序；

应用客户端的信息处理能力；

消息有效期限。

15.一种如权利要求12-13中任一项所述的系统，其中，所述参考轮询周期被所述应用用于重新设定该应用的轮询时钟。

16.一种如权利要求15所述的系统，所述应用根据重新设定的轮询时钟发送下一次信息轮询请求。

17.一种如权利要求12-13中任一项所述的系统，所述应用根据应用客户端的负载情况以及接收到的参考轮询周期，确定发送下一次信息轮询请求的轮询周期。

18.一种如权利要求17所述的系统，所述确定的发送下一次信息轮询请求的轮询周期大于所述参考轮询周期。

19.一种如权利要求12-13中任一项所述的系统，其中所述应用根据相关紧急请求，立即发送对特定消息的轮询请求。

Images