CN105101295A - 一种心跳报文发送方法及装置 - Google Patents

Abstract

本发明实施例公开了一种心跳报文发送方法及装置，该方法包括：接收应用的注册信息；根据所述注册信息生成并存储所述应用的心跳报文；根据预设的心跳报文发送周期进行心跳报文发送。通过本发明实施例所述的技术方案，按照预设的心跳报文发送周期进行心跳报文发送，能够避免对无线网络侧及时分配资源的不利影响，减少终端侧和无线网络侧的信令状态切换次数，提高系统效率，节省系统资源。

Description

一种心跳报文发送方法及装置

技术领域

本发明涉及终端应用技术领域，尤其涉及一种心跳报文发送方法及装置。

背景技术

平板电脑、智能手机等移动终端引入多样化的移动应用。移动应用主要依靠无线移动网络及其核心网接入互联网，采用客户端-服务器模式的移动应用要与其服务器频繁交互数据。

现有的移动应用为保持与其服务器的长时间连接，通常使用定时发送心跳报文的机制，例如即时通讯(IM)应用。心跳报文一般通过有连接的传输控制协议(TransmissionControlProtocol，TCP)或无连接的用户数据报协议(UserDataProtocol，UDP)发送，在约定时限内向服务器通告客户端情况。

为降低延迟，心跳报文通常尺寸短小。而受限于无线移动接入网络的资源，移动终端在建立数据连接时要申请使用无线信道，这个过程既消耗无线网络侧的系统资源，也消耗终端侧的系统资源。移动应用为保持连接长时间有效，如果过于频繁发送心跳报文，将使该无线信道的相关资源无法释放，对无线网络侧及时分配资源造成不利影响；并且，密集发送心跳报文将使得终端侧和无线网络侧的信令状态频繁切换，效率低下并且耗能巨大。

发明内容

有鉴于此，为解决现有存在的技术问题，本发明实施例提供：

一种心跳报文发送方法，包括：

接收应用的注册信息；

根据所述注册信息生成并存储所述应用的心跳报文；

根据预设的心跳报文发送周期进行心跳报文发送。

较佳的，所述注册信息包括以下一项或多项：

应用的进程ID、应用使用的源端口号、应用对端服务器的目标地址、应用对端服务器的目标端口号、应用与服务器间的心跳数据。

较佳的，所述根据注册信息生成应用的心跳报文，包括：

以用户终端当前有效连接的IP地址作为源地址、以应用注册信息中应用使用的源端口号作为源端口号、以应用对端服务器的目标地址和端口号作为目标地址和端口号、以及以应用与其服务器间的心跳数据作为心跳报文的净荷，生成所述应用的心跳报文。

较佳的，所述根据预设的心跳报文发送周期进行心跳报文发送，包括：

在每个心跳报文发送周期，分别判断各已生成的心跳报文对应的应用的存活状态，如果应用存活，则发送所述应用的心跳报文；如果应用消亡，则删除所述应用的心跳报文。

较佳的，所述分别判断各已生成的心跳报文对应的应用的存活状态，包括：根据心跳报文的生成顺序，依次判断心跳报文对应应用的存活状态。

较佳的，该方法还包括：

根据应用状态或来自应用的注销请求，删除所述应用的心跳报文。

较佳的，所述接收应用的注册信息之后，该方法还包括：

向所述应用返回注册结果。

较佳的，该方法还包括：

获取用户配置信息，或者，获取网络侧的配置信息；

根据所述配置信息设置心跳报文发送周期。

一种心跳报文发送装置，包括：注册模块、心跳报文生成模块、心跳报文存储模块、控制模块和心跳报文发送模块；其中，

所述注册模块，用于接收应用的注册信息；

所述心跳报文生成模块，用于根据所述注册信息生成所述应用的心跳报文；

所述心跳报文存储模块，用于存储所述生成的心跳报文；

所述控制模块，用于根据预设的心跳报文发送周期控制心跳报文发送；

所述心跳报文发送模块，用于发送心跳报文。

较佳的，所述注册信息包括以下一项或多项：应用的进程ID、应用使用的源端口号、应用对端服务器的目标地址、应用对端服务器的目标端口号、应用与服务器间的心跳数据，

所述心跳报文生成模块，具体用于以用户终端当前有效连接的IP地址作为源地址、以应用注册信息中应用使用的源端口号作为源端口号、以应用对端服务器的目标地址和端口号作为目标地址和端口号、以及以应用与其服务器间的心跳数据作为心跳报文的净荷，生成所述应用的心跳报文。

较佳的，所述控制模块，具体用于在每个心跳报文发送周期，判断所有已生成的心跳报文对应的应用的存活状态，如果应用存活，则通知心跳报文发送模块发送所述应用的心跳报文；如果应用消亡，则删除心跳报文存储模块中所述应用的心跳报文。

较佳的，所述控制模块，具体用于根据心跳报文的生成顺序，依次判断心跳报文对应应用的存活状态，并在应用存活时，通知心跳报文发送模块发送所述应用的心跳报文。

较佳的，所述控制模块，还用于根据应用状态或来自应用的注销请求，删除心跳报文存储模块中所述应用的心跳报文。

较佳的，该装置还包括注册结果发送模块，

所述注册结果发送模块，用于在注册模块接收应用的注册信息之后，向所述应用返回注册结果。

较佳的，该装置还包括配置信息获取模块，

所述配置信息获取模块，用于获取用户配置信息，或者，获取网络侧的配置信息；

所述控制模块，用于根据所述配置信息设置心跳报文发送周期。

本发明实施例所述的心跳报文发送方法及装置，接收应用的注册信息；根据所述注册信息生成并存储所述应用的心跳报文；根据预设的心跳报文发送周期进行心跳报文发送。通过本发明实施例所述的技术方案，按照预设的心跳报文发送周期进行心跳报文发送，能够避免对无线网络侧及时分配资源的不利影响，减少终端侧和无线网络侧的信令状态切换次数，提高系统效率，节省系统资源。

附图说明

图1为本发明一实施例一种心跳报文发送方法流程示意图；

图2为本发明一实施例一种心跳报文发送装置；

图3为本发明另一实施例一种心跳报文发送装置。

具体实施方式

在本发明的各种实施例中：接收应用的注册信息；根据所述注册信息生成并存储所述应用的心跳报文；根据预设的心跳报文发送周期进行心跳报文发送。

许多运营商结合自身网络情况，例如无线信令状态切换时钟、核心网防火墙连接状态保留时效等因素，向移动应用开发者给出心跳机制的最优方案建议，依照其方案设定心跳周期能够以合理频度发送心跳报文，达到维护数据连接和降低资源消耗的最佳平衡。一些相关技术，建议应用开发者利用客户端与服务器间交互的数据报文来维护连接以减少心跳次数，或者根据探测到的终端侧数据通信繁忙程度来动态调整心跳频度。也有一些相关技术，在网络侧设置心跳代理服务器，探知来自终端侧的心跳报文后在核心网代其发送心跳，并且在终端侧抑制心跳报文，将心跳转移到有线网络中从而降低无线网络的通信压力。

但是，运营商对移动应用开发者提出的心跳优化建议缺乏约束性，开发者即使遵循运营商的方案，心跳周期的设定因为缺乏灵活性和适应性，需要针对不同运营商网络分别设定心跳周期，并且同一家运营商建议的心跳周期一旦变化将导致应用修改重新发布，加重开发者负担使其失去配合的积极性；

通过普通数据报文替代心跳的技术，在客户端与服务器间长时间无数据交互时优势并不明显，仍然存在依赖定时心跳报文维持连接的问题。实时统计通信负荷来动态调整心跳频度的技术，在实现上增加了算法复杂度，准确度有限，实时统计数据量也会消耗大量系统资源。在网络侧设置心跳代理服务器的技术需要运营商改造网络，对不同应用的心跳需要统计分析其特征方能区别复制，准确度不高。

上述技术最大的问题还在于，用户终端存在多个发生心跳的应用时，即使每个应用有意优化了其心跳频度，不同应用的心跳机制多样化导致系统总体缺乏统一优化，使得这些应用的各自优化失去意义。

本发明实施例为移动应用提供统一心跳机制，在智能终端系统上统一增设心跳服务并开放系统级调用，向上层应用提供一种标准化的心跳机制，上层应用无需自主负责心跳而统一交给系统执行，以实现系统总体的心跳方案优化。

图1为本发明实施例所述的一种心跳报文发送方法流程示意图，如图1所示，该方法包括：

步骤101：接收应用的注册信息；

步骤102：根据所述注册信息生成并存储所述应用的心跳报文；

步骤103：根据预设的心跳报文发送周期进行心跳报文发送。

需要说明的是，本发明实施例所述的方法一般由心跳服务实现，该心跳服务可以底层库形式预置在终端操作系统中，也可以以中间件形式随应用或独立安装在用户终端系统上。用户终端上的有心跳需求的应用启动并处于在线状态后，立即调用心跳服务的接口进行注册。

需要说明的是，实际应用中，也可以存储应用注册信息，在删除应用报文时相应删除其注册信息。

可选的，在本发明另一实施例中，所述注册信息包括以下一项或多项：

应用的进程ID、应用使用的源端口号、应用对端服务器的目标地址、应用对端服务器的目标端口号、应用与服务器间的心跳数据。这里，注册信息的部分或全部可加密。

可选的，在本发明另一实施例中，步骤102所述根据注册信息生成应用的心跳报文，包括：

以用户终端当前有效连接的IP地址作为源地址、以应用注册信息中应用使用的源端口号作为源端口号、以应用对端服务器的目标地址和端口号作为目标地址和端口号、以及以应用与其服务器间的心跳数据作为心跳报文的净荷，生成所述应用的心跳报文。

可选的，在本发明另一实施例中，步骤103所述根据预设的心跳报文发送周期进行心跳报文发送，包括：

在每个心跳报文发送周期，分别判断各已生成的心跳报文对应的应用的存活状态，如果应用存活，则发送所述应用的心跳报文；如果应用消亡，则删除所述应用的心跳报文。这里，心跳服务可以维持一个计时器，计时周期等于预先设置的心跳报文发送周期，计时器到时后，心跳服务重置计时器，并依据进程ID检查应用的存活状态。

可选的，在本发明另一实施例中，所述分别判断各已生成的心跳报文对应的应用的存活状态，包括：根据心跳报文的生成顺序，依次判断心跳报文对应应用的存活状态。在实际应用中，心跳服务每次生成应用的心跳报文后，可将该应用的心跳报文(进程ID及对应的心跳报文)保存于发送队列缓存中，这样，在心跳报文发送周期，便可按照队列顺序进行判断。

可选的，在本发明另一实施例中，该方法还包括：根据应用状态或来自应用的注销请求，删除所述应用的心跳报文。例如，上层应用在状态变为离线后，或者应用退出前，调用心跳服务的接口进行注销，则心跳服务将其心跳报文从发送队列缓存中剔除，进一步的，如果存储有其注册信息，同时删除其注册信息。

可选的，在本发明另一实施例中，所述接收应用的注册信息之后，该方法还包括：向所述应用返回注册结果。这里，心跳服务根据自身处理能力、资源占用情况等确定应用是否能够成功注册，并且向应用返回相应的注册结果，应用收到注册成功的结果后，将心跳过程委托给系统心跳服务，不再自主其心跳过程。需要说明的是，本发明的实施例主要针对注册成功的场景进行说明。

可选的，在本发明另一实施例中，该方法还包括：

获取用户配置信息，或者，获取网络侧的配置信息；

根据所述配置信息设置心跳报文发送周期。

需要说明的是，用户配置信息可以是具体的心跳周期值，也可以是增大心跳周期、减小心跳周期等调整信息。

具体的，用户可以随时通过系统设置来设定、调整期望的心跳周期，一般而言该心跳周期要遵循用户所属运营商的建议和指导。另外，心跳服务周期的设置，也可以通过部署在运营商网络侧的服务器配合来实现，比如终端侧的心跳服务与服务器交互取得运营商期望的心跳周期值，而无需用户介入。

本发明实施例还相应地提出了一种心跳报文发送装置，该心跳报文发送装置可以通过预置或安装心跳服务实现，如图2所示，该装置包括：注册模块21、心跳报文生成模块22、心跳报文存储模块23、控制模块24和心跳报文发送模块25；其中，

注册模块21，用于接收应用的注册信息；

心跳报文生成模块22，用于根据所述注册信息生成所述应用的心跳报文；

心跳报文存储模块23，用于存储所述生成的心跳报文；

控制模块24，用于根据预设的心跳报文发送周期控制心跳报文发送；

心跳报文发送模块25，用于发送心跳报文。

可选的，在本发明另一实施例中，所述注册信息包括以下一项或多项：应用的进程ID、应用使用的源端口号、应用对端服务器的目标地址、应用对端服务器的目标端口号、应用与服务器间的心跳数据，

相应的，心跳报文生成模块22，具体用于以用户终端当前有效连接的IP地址作为源地址、以应用注册信息中应用使用的源端口号作为源端口号、以应用对端服务器的目标地址和端口号作为目标地址和端口号、以及以应用与其服务器间的心跳数据作为心跳报文的净荷，生成所述应用的心跳报文。

可选的，在本发明另一实施例中，控制模块24，具体用于在每个心跳报文发送周期，判断所有已生成的心跳报文对应的应用的存活状态，如果应用存活，则通知心跳报文发送模块25发送所述应用的心跳报文；如果应用消亡，则删除心跳报文存储模块23中所述应用的心跳报文。

可选的，在本发明另一实施例中，控制模块24，具体用于根据心跳报文的生成顺序，依次判断心跳报文对应应用的存活状态，并在应用存活时，通知心跳报文发送模块25发送所述应用的心跳报文。

可选的，在本发明另一实施例中，控制模块24，还用于根据应用状态或来自应用的注销请求，删除心跳报文存储模块23中所述应用的心跳报文。

可选的，所述注册模块21，还用于在接收应用的注册信息之后，向所述应用返回注册结果。

可选的，在本发明另一实施例中，如图3所示，该装置还包括配置信息获取模块26，

配置信息获取模块26，用于获取用户配置信息，或者，获取网络侧的配置信息；

控制模块24，用于根据所述配置信息设置心跳报文发送周期。

本发明实施例所述的技术方案，可以大大简化用户终端上多个移动应用的心跳过程，将各应用的心跳过程统一交给系统心跳服务执行，使心跳机制标准化，也保证心跳周期的一致性，能够大大降低终端侧能耗和无线移动网络资源负担。同时基本不增加应用开发者设计和维护负担，也无需对现有运营网络进行改造。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (15)

1.一种心跳报文发送方法，其特征在于，该方法包括：

接收应用的注册信息；

根据所述注册信息生成并存储所述应用的心跳报文；

根据预设的心跳报文发送周期进行心跳报文发送。

2.根据权利要求1所述的方法，其特征在于，所述注册信息包括以下一项或多项：

应用的进程ID、应用使用的源端口号、应用对端服务器的目标地址、应用对端服务器的目标端口号、应用与服务器间的心跳数据。

3.根据权利要求2所述的方法，其特征在于，所述根据注册信息生成应用的心跳报文，包括：

以用户终端当前有效连接的IP地址作为源地址、以应用注册信息中应用使用的源端口号作为源端口号、以应用对端服务器的目标地址和端口号作为目标地址和端口号、以及以应用与其服务器间的心跳数据作为心跳报文的净荷，生成所述应用的心跳报文。

4.根据权利要求1所述的方法，其特征在于，所述根据预设的心跳报文发送周期进行心跳报文发送，包括：

在每个心跳报文发送周期，分别判断各已生成的心跳报文对应的应用的存活状态，如果应用存活，则发送所述应用的心跳报文；如果应用消亡，则删除所述应用的心跳报文。

5.根据权利要求4所述的方法，其特征在于，所述分别判断各已生成的心跳报文对应的应用的存活状态，包括：根据心跳报文的生成顺序，依次判断心跳报文对应应用的存活状态。

6.根据权利要求1至5任一项所述的方法，其特征在于，该方法还包括：

根据应用状态或来自应用的注销请求，删除所述应用的心跳报文。

7.根据权利要求1至5任一项所述的方法，其特征在于，所述接收应用的注册信息之后，该方法还包括：

向所述应用返回注册结果。

8.根据权利要求1至5任一项所述的方法，其特征在于，该方法还包括：

获取用户配置信息，或者，获取网络侧的配置信息；

根据所述配置信息设置心跳报文发送周期。

9.一种心跳报文发送装置，其特征在于，该装置包括：注册模块、心跳报文生成模块、心跳报文存储模块、控制模块和心跳报文发送模块；其中，

所述注册模块，用于接收应用的注册信息；

所述心跳报文生成模块，用于根据所述注册信息生成所述应用的心跳报文；

所述心跳报文存储模块，用于存储所述生成的心跳报文；

所述控制模块，用于根据预设的心跳报文发送周期控制心跳报文发送；

所述心跳报文发送模块，用于发送心跳报文。

10.根据权利要求9所述的装置，其特征在于，所述注册信息包括以下一项或多项：应用的进程ID、应用使用的源端口号、应用对端服务器的目标地址、应用对端服务器的目标端口号、应用与服务器间的心跳数据，

所述心跳报文生成模块，具体用于以用户终端当前有效连接的IP地址作为源地址、以应用注册信息中应用使用的源端口号作为源端口号、以应用对端服务器的目标地址和端口号作为目标地址和端口号、以及以应用与其服务器间的心跳数据作为心跳报文的净荷，生成所述应用的心跳报文。

11.根据权利要求9所述的装置，其特征在于，

所述控制模块，具体用于在每个心跳报文发送周期，判断所有已生成的心跳报文对应的应用的存活状态，如果应用存活，则通知心跳报文发送模块发送所述应用的心跳报文；如果应用消亡，则删除心跳报文存储模块中所述应用的心跳报文。

12.根据权利要求11所述的装置，其特征在于，

所述控制模块，具体用于根据心跳报文的生成顺序，依次判断心跳报文对应应用的存活状态，并在应用存活时，通知心跳报文发送模块发送所述应用的心跳报文。

13.根据权利要求9至12任一项所述的装置，其特征在于，

所述控制模块，还用于根据应用状态或来自应用的注销请求，删除心跳报文存储模块中所述应用的心跳报文。

14.根据权利要求9至12任一项所述的装置，其特征在于，该装置还包括注册结果发送模块，

所述注册结果发送模块，用于在注册模块接收应用的注册信息之后，向所述应用返回注册结果。

15.根据权利要求9至12任一项所述的装置，其特征在于，该装置还包括配置信息获取模块，

所述配置信息获取模块，用于获取用户配置信息，或者，获取网络侧的配置信息；

所述控制模块，用于根据所述配置信息设置心跳报文发送周期。