一种心跳报文发送方法及装置的制造方法
【技术领域】
[0001]本发明涉及终端应用技术领域，尤其涉及一种心跳报文发送方法及装置。
【背景技术】
[0002]平板电脑、智能手机等移动终端引入多样化的移动应用。移动应用主要依靠无线移动网络及其核心网接入互联网，采用客户端-服务器模式的移动应用要与其服务器频繁交互数据。
[0003]现有的移动应用为保持与其服务器的长时间连接，通常使用定时发送心跳报文的机制，例如即时通讯(IM)应用。心跳报文一般通过有连接的传输控制协议(Transmiss1nControl Protocol, TCP)或无连接的用户数据报协议(User Data Protocol, UDP)发送,在约定时限内向服务器通告客户端情况。
[0004]为降低延迟，心跳报文通常尺寸短小。而受限于无线移动接入网络的资源，移动终端在建立数据连接时要申请使用无线信道，这个过程既消耗无线网络侧的系统资源，也消耗终端侧的系统资源。移动应用为保持连接长时间有效，如果过于频繁发送心跳报文，将使该无线信道的相关资源无法释放，对无线网络侧及时分配资源造成不利影响；并且，密集发送心跳报文将使得终端侧和无线网络侧的信令状态频繁切换，效率低下并且耗能巨大。
【发明内容】
[0005]有鉴于此，为解决现有存在的技术问题，本发明实施例提供:
[0006]一种心跳报文发送方法，包括:
[0007]接收应用的注册信息；
[0008]根据所述注册信息生成并存储所述应用的心跳报文；
[0009]根据预设的心跳报文发送周期进行心跳报文发送。
[0010]较佳的，所述注册信息包括以下一项或多项:
[0011]应用的进程ID、应用使用的源端口号、应用对端服务器的目标地址、应用对端服务器的目标端口号、应用与服务器间的心跳数据。
[0012]较佳的，所述根据注册信息生成应用的心跳报文，包括:
[0013]以用户终端当前有效连接的IP地址作为源地址、以应用注册信息中应用使用的源端口号作为源端口号、以应用对端服务器的目标地址和端口号作为目标地址和端口号、以及以应用与其服务器间的心跳数据作为心跳报文的净荷，生成所述应用的心跳报文。
[0014]较佳的，所述根据预设的心跳报文发送周期进行心跳报文发送，包括:
[0015]在每个心跳报文发送周期，分别判断各已生成的心跳报文对应的应用的存活状态，如果应用存活，则发送所述应用的心跳报文；如果应用消亡，则删除所述应用的心跳报文。
[0016]较佳的，所述分别判断各已生成的心跳报文对应的应用的存活状态，包括:根据心跳报文的生成顺序，依次判断心跳报文对应应用的存活状态。
[0017]较佳的，该方法还包括:
[0018]根据应用状态或来自应用的注销请求，删除所述应用的心跳报文。
[0019]较佳的，所述接收应用的注册信息之后，该方法还包括:
[0020]向所述应用返回注册结果。
[0021 ] 较佳的，该方法还包括:
[0022]获取用户配置信息，或者，获取网络侧的配置信息；
[0023]根据所述配置信息设置心跳报文发送周期。
[0024]一种心跳报文发送装置，包括:注册模块、心跳报文生成模块、心跳报文存储模块、控制模块和心跳报文发送模块；其中，
[0025]所述注册模块，用于接收应用的注册信息；
[0026]所述心跳报文生成模块，用于根据所述注册信息生成所述应用的心跳报文；
[0027]所述心跳报文存储模块，用于存储所述生成的心跳报文；
[0028]所述控制模块，用于根据预设的心跳报文发送周期控制心跳报文发送；
[0029]所述心跳报文发送模块，用于发送心跳报文。
[0030]较佳的，所述注册信息包括以下一项或多项:应用的进程ID、应用使用的源端口号、应用对端服务器的目标地址、应用对端服务器的目标端口号、应用与服务器间的心跳数据，
[0031]所述心跳报文生成模块，具体用于以用户终端当前有效连接的IP地址作为源地址、以应用注册信息中应用使用的源端口号作为源端口号、以应用对端服务器的目标地址和端口号作为目标地址和端□号、以及以应用与其服务器间的心跳数据作为心跳报文的净荷，生成所述应用的心跳报文。
[0032]较佳的，所述控制模块，具体用于在每个心跳报文发送周期，判断所有已生成的心跳报文对应的应用的存活状态，如果应用存活，则通知心跳报文发送模块发送所述应用的心跳报文；如果应用消亡，则删除心跳报文存储模块中所述应用的心跳报文。
[0033]较佳的，所述控制模块，具体用于根据心跳报文的生成顺序，依次判断心跳报文对应应用的存活状态，并在应用存活时，通知心跳报文发送模块发送所述应用的心跳报文。
[0034]较佳的，所述控制模块，还用于根据应用状态或来自应用的注销请求，删除心跳报文存储模块中所述应用的心跳报文。
[0035]较佳的，该装置还包括注册结果发送模块，
[0036]所述注册结果发送模块，用于在注册模块接收应用的注册信息之后，向所述应用返回注册结果。
[0037]较佳的，该装置还包括配置信息获取模块，
[0038]所述配置信息获取模块，用于获取用户配置信息，或者，获取网络侧的配置信息；
[0039]所述控制模块，用于根据所述配置信息设置心跳报文发送周期。
[0040]本发明实施例所述的心跳报文发送方法及装置，接收应用的注册信息；根据所述注册信息生成并存储所述应用的心跳报文；根据预设的心跳报文发送周期进行心跳报文发送。通过本发明实施例所述的技术方案，按照预设的心跳报文发送周期进行心跳报文发送，能够避免对无线网络侧及时分配资源的不利影响，减少终端侧和无线网络侧的信令状态切换次数，提高系统效率，节省系统资源。
【附图说明】
[0041]图1为本发明一实施例一种心跳报文发送方法流程示意图；
[0042]图2为本发明一实施例一种心跳报文发送装置；
[0043]图3为本发明另一实施例一种心跳报文发送装置。
【具体实施方式】
[0044]在本发明的各种实施例中:接收应用的注册信息；根据所述注册信息生成并存储所述应用的心跳报文；根据预设的心跳报文发送周期进行心跳报文发送。
[0045]许多运营商结合自身网络情况，例如无线信令状态切换时钟、核心网防火墙连接状态保留时效等因素，向移动应用开发者给出心跳机制的最优方案建议，依照其方案设定心跳周期能够以合理频度发送心跳报文，达到维护数据连接和降低资源消耗的最佳平衡。一些相关技术，建议应用开发者利用客户端与服务器间交互的数据报文来维护连接以减少心跳次数，或者根据探测到的终端侧数据通信繁忙程度来动态调整心跳频度。也有一些相关技术，在网络侧设置心跳代理服务器，探知来自终端侧的心跳报文后在核心网代其发送心跳，并且在终端侧抑制心跳报文，将心跳转移到有线网络中从而降低无线网络的通信压力。
[0046]但是，运营商对移动应用开发者提出的心跳优化建议缺乏约束性，开发者即使遵循运营商的方案，心跳周期的设定因为缺乏灵活性和适应性，需要针对不同运营商网络分别设定心跳周期，并且同一家运营商建议的心跳周期一旦变化将导致应用修改重新发布，加重开发者负担使其失去配合的积极性；
[0047]通过普通数据报文替代心跳的技术，在客户端与服务器间长时间无数据交互时优势并不明显，仍然存在依赖定时心跳报文维持连接的问题。实时统计通信负荷来动态调整心跳频度的技术，在实现上增加了算法复杂度，准确度有限，实时统计数据量也会消耗大量系统资源。在网络侧设置心跳代理服务器的技术需要运营商改造网络，对不同应用的心跳需要统计分析其特征方能区别复制，准确度不高。
[0048]上述技术最大的问题还在于，用户终端存在多个发生心跳的应用时，即使每个应用有意优化了其心跳频度，不同应用的心跳机制多样化导致系统总体缺乏统一优化，使得这些应用的各自优化失去意义。
[0049]本发明实施例为移动应用提供统一心跳机制，在智能终端系统上统一增设心跳服务并开放系统级调用，向上层应用提供一种标准化的心跳机制，上层应用无需自主负责心跳而统一交给系统执行，以实现系统总体的心跳方案优化。
[0050]图1为本发明实施例所述的一种心跳报文发送方法流程示意图，如图1所示，该方法包括:
[0051]步骤101:接收应用的注册信息；
[0052]步骤102:根据所述注册信息生成并存储所述应用的心跳报文；
[0053]步骤103:根据预设的心跳报文发送周期进行心跳报文发送。
[0054]需要说明的是，本发明实施例所述的方法一般由心跳服务实现，该心跳服务可以底层库形式预置在终端操作系统中，也可以以中间件形式随应用或独立安装在用户终端系统上。用户终端上的有心跳需求的应用启动并处于在线状态后，立即调用心跳服务的接口进行注册。
[0055]需要说明的是，实际应用中，也可以存储应用注册信息，在删除应用报文时相应删除其注册信息。
[0056]可选的，在本发明另一实施例中，所述注册信息包括以下一项或多项:
[0057]应用的进程ID、应用使用的源端口号、应用对端服务器的目标地址、应用对端服务器的目标端口号、应用与服务器间的心跳数据。这里，注册信息的部分或全部可加密。
[0058]可选的，在本发明另一实施例中，步骤102所述根据注册信息生成应用的心跳报文，包括:
[0059]以用户终端当前有效连接的IP地址作为源地址、以应用注册信息中应用使用的源端口号作为源端口号、以应用对端服务器的目标地址和端口号作为目标地址和端口号、以及以应用与其服务器间的心跳数据作为心跳报文的净荷，生成所述应用的心跳报文。
[0060]可选的，在本发明另一实施例中，步骤103所述根据预设的心跳报文发送