一种高效能的心跳保活方法与流程

1.本发明涉及信号传输技术领域，尤其涉及心跳保活方法。


背景技术：

2.在电子技术领域，一个系统当中通常有多个功能模块共同协作，才能使整个系统正常地对外提供服务。而确定系统中的每一个功能模块的运行状态是否正常，则需要有相应的功能模块状态监测机制，业内通常的做法就是采用心跳保活机制。
3.在传统的心跳保活机制中，在系统当中设有一个专门负责管理其他所有功能模块的特殊功能模块，它通常被称为主设备，而其余的功能模块则被称为从设备。在这样的一套系统当中，从设备只需要周期性地向主设备发送心跳包。与之对应的，主设备只需要被动地接收从设备发来的心跳包，并且在收到心跳包的时候将心跳保活超时时长置为零即可。
4.然而，以上技术方案的网络资源消耗和响应效率是无法兼顾的。
5.如果将心跳包收发周期设置得较小，则可以提高系统的响应效率，但是网络资源的消耗会增加；如果将心跳包收发周期设置得较大，则可以减少网络资源的消耗，但是系统的响应效率会下降。


技术实现要素：

6.本发明的目的在于克服现有心跳保活机制不能兼顾网络资源消耗和响应效率的问题，提供一种高效能的心跳保活方法，当主设备接收从设备心跳包超时的时候，主动向从设备发起询问。
7.本发明的目的是通过以下技术方案来实现的：
8.一种高效能的心跳保活方法，包括以下具体步骤：
9.步骤一：从设备周期性地向主设备发送心跳包，发送周期为t0；
10.步骤二：主设备等待接收从设备发送的心跳包，并同步计时；
11.步骤三：主设备判断等待接收心跳包时长是否超过预设值，若未超时，则将心跳包请求次数记为0，若超时，则需进一步判断心跳包请求次数；
12.步骤四：在主设备判断心跳包请求超时后，查询心跳包请求次数是否超过心跳包请求次数上限n，若心跳包请求次数小于n，则主动向从设备发送心跳包请求消息，并将心跳包请求次数累加1；若心跳包请求次数大于n，则确定从设备已掉线。
13.步骤二中所述同步计时具体为主设备在从设备传输心跳包的同时进行计时。
14.所述主设备等待心跳包时长预设值为t0 t1，t0为从设备心跳包发送周期时间，t1为心跳包传输时长。
15.所述t0和t1根据实际应用进行调节。
16.本发明的有益效果：
17.本发明兼顾了网络资源消耗和响应效率，使得心跳保活机制可以在不增加网络资源消耗的情况下，大幅提高主设备发现从设备掉线事件的响应效率。
附图说明
18.图1是本发明的方法流程图；
19.图2是传统从设备周期性发送心跳包流程图；
20.图3是传统主设备响应心跳包消息流程图；
21.图4是传统主设备等待心跳包流程图；
22.图5是从设备响应心跳包请求消息流程图。
具体实施方式
23.为了对本发明的技术特征、目的和效果有更加清楚的理解，现对照附图说明本发明的具体实施方式。
24.首先定义几个必要的常量：
25.t0心跳包发送周期t1心跳包传输时长上限t2心跳超时时长上限t3消息接收周期n心跳包请求次数上限
26.表1常量定义列表
27.实施例1，如图1所示，一种高效能的心跳保活方法，包括以下具体步骤：
28.步骤一：从设备周期性地向主设备发送心跳包，发送周期为t0；
29.步骤二：主设备等待接收从设备发送的心跳包，并同步计时；
30.步骤三：主设备判断等待接收心跳包时长是否超过预设值，若未超时，则将心跳包请求次数记为0，若超时，则需进一步判断心跳包请求次数；
31.步骤四：在主设备判断心跳包请求超时后，查询心跳包请求次数是否超过心跳包请求次数上限n，若心跳包请求次数小于n，则主动向从设备发送心跳包请求消息，并将心跳包请求次数累加1；若心跳包请求次数大于n，则确定从设备已掉线。
32.步骤二中所述同步计时具体为主设备在从设备传输心跳包的同时进行计时。
33.所述主设备等待心跳包时长预设值为t0 t1，t0为从设备心跳包发送周期时间，t1为心跳包传输时长。
34.所述t0和t1根据实际应用进行调节。
35.在传统的心跳保活机制当中，如图2所示，从设备只需要周期性地向主设备发送心跳包；相应的，如图3所示，主设备也只需要被动地接收从设备发来的心跳包；当主设备发现心跳超时时长达到一定程度的时候，如图4所示，则可以断定从设备已经掉线。
36.在本发明中，从设备除了周期性地向主设备发送心跳包之外，还需要响应主设备发送来的心跳包请求消息。也就是说，从设备除了周期性地向主设备发送心跳包之外，还需要在收到主设备发来的心跳包请求消息的时候立即向主设备发送一个心跳包消息，其运行逻辑的流程图如附图5所示。
37.与之对应的，主设备也不再只是如附图4所示的流程图那样只是被动地等待心跳超时。而是在发现心跳超时时长达到从设备发送心跳包周期的时候，主动地向从设备发出心跳包请求消息，以便于快速地确认从设备当前是否在线，其运行逻辑的流程图如附图1所
示。
38.简而言之，在传统的心跳保活机制当中，主设备的运行逻辑如附图3和附图 4所示，从设备的运行逻辑如附图2所示；在本发明的技术方案当中，主设备的运行逻辑如附图1和附图3所示，从设备的运行逻辑如附图2和附图5所示。
39.首先假定应用场景为通信基站内的软件系统，主设备为oam进程，从设备为 pdcp进程。
40.这里需要注意的是，此处为便于表述，仅选择众多业务进程中的一个作为本实施例中的从设备。如果需要使oam进程可以监测其他业务进程的运行状态，其实施方式与本实施例相同。
41.本实施例中，主设备为oam进程，从设备为pdcp进程，定义心跳包发送周期t0为30s，心跳包传输时长上限t1为1s，心跳超时时长上限t2为90s，消息接收周期t3为0.1s，心跳包请求次数上限为3。
42.当从设备pdcp进程在线时，由于从设备pdcp进程会周期性地向主设备oam 进程发送心跳包，从设备pdcp进程和主设备oam进程之间仅需要每隔30s进行一次心跳包的收发操作。在此情景之下，本技术方案的表现与传统心跳保活机制完全一致。
43.当从设备pdcp进程掉线时主设备oam进程将在等待31s(即t0 t1)之后，发现心跳包已超时，此时的主设备oam进程将会以每秒1次的频率向从设备pdcp 进程发送心跳包请求消息。如果在此过程当中，主设备oam进程接收到了来自从设备pdcp进程的心跳包，则重新回到被动等待从设备心跳包的循环当中。如果主设备oam进程在连续3次向从设备pdcp进程发送心跳包请求消息之后，仍然没有接收到任何一个来自于从设备pdcp进程的心跳包，则可以断定从设备 pdcp进程已经掉线。
44.综上所述，当从设备pdcp进程在线的时候，本技术方案与传统的心跳保活机制一样，只需每隔30s进行一次心跳包的收发操作，因此网络资源消耗与传统的心跳保活机制相同。当从设备pdcp进程掉线的时候，传统心跳保活机制需要等待90s之后才能断定从设备pdcp进程已经掉线，而本技术方案仅需要 33s(30s 3*1s)即可断定从设备pdcp进程已经掉线，响应效率相较传统心跳保活机制大幅提升。
45.实施例2，如图1所示，一种高效能的心跳保活方法，包括以下具体步骤：
46.步骤一：从设备周期性地向主设备发送心跳包，发送周期为t0；
47.步骤二：主设备等待接收从设备发送的心跳包，并同步计时；
48.步骤三：主设备判断等待接收心跳包时长是否超过预设值，若未超时，则将心跳包请求次数记为0，若超时，则需进一步判断心跳包请求次数；
49.步骤四：在主设备判断心跳包请求超时后，查询心跳包请求次数是否超过心跳包请求次数上限n，若心跳包请求次数小于n，则主动向从设备发送心跳包请求消息，并将心跳包请求次数累加1；若心跳包请求次数大于n，则确定从设备已掉线。
50.步骤二中所述同步计时具体为主设备在从设备传输心跳包的同时进行计时。
51.所述主设备等待心跳包时长预设值为t0 t1，t0为从设备心跳包发送周期时间，t1为心跳包传输时长。
52.所述t0和t1根据实际应用进行调节。
53.在传统的心跳保活机制当中，如图2所示，从设备只需要周期性地向主设备发送心
跳包；相应的，如图3所示，主设备也只需要被动地接收从设备发来的心跳包；当主设备发现心跳超时时长达到一定程度的时候，如图4所示，则可以断定从设备已经掉线。
54.在本发明中，从设备除了周期性地向主设备发送心跳包之外，还需要响应主设备发送来的心跳包请求消息。也就是说，从设备除了周期性地向主设备发送心跳包之外，还需要在收到主设备发来的心跳包请求消息的时候立即向主设备发送一个心跳包消息，其运行逻辑的流程图如附图5所示。
55.与之对应的，主设备也不再只是如附图4所示的流程图那样只是被动地等待心跳超时。而是在发现心跳超时时长达到从设备发送心跳包周期的时候，主动地向从设备发出心跳包请求消息，以便于快速地确认从设备当前是否在线，其运行逻辑的流程图如附图1所示。
56.简而言之，在传统的心跳保活机制当中，主设备的运行逻辑如附图3和附图 4所示，从设备的运行逻辑如附图2所示；在本发明的技术方案当中，主设备的运行逻辑如附图1和附图3所示，从设备的运行逻辑如附图2和附图5所示。
57.首先假定应用场景为通信基站内的软件系统，主设备为oam进程，从设备为 pdcp进程。
58.这里需要注意的是，此处为便于表述，仅选择众多业务进程中的一个作为本实施例中的从设备。如果需要使oam进程可以监测其他业务进程的运行状态，其实施方式与本实施例相同。
59.本实施例中，主设备为oam进程，从设备为pdcp进程，定义心跳包发送周期t0为20s，心跳包传输时长上限t1为2s，心跳超时时长上限t2为60s，消息接收周期t3为0.1s，心跳包请求次数上限为3。
60.当从设备pdcp进程在线时，由于从设备pdcp进程会周期性地向主设备oam 进程发送心跳包，从设备pdcp进程和主设备oam进程之间仅需要每隔20s进行一次心跳包的收发操作。在此情景之下，本技术方案的表现与传统心跳保活机制完全一致。
61.当从设备pdcp进程掉线时主设备oam进程将在等待22s(即t0 t1)之后，发现心跳包已超时，此时的主设备oam进程将会以每两秒1次的频率向从设备 pdcp进程发送心跳包请求消息。如果在此过程当中，主设备oam进程接收到了来自从设备pdcp进程的心跳包，则重新回到被动等待从设备心跳包的循环当中。如果主设备oam进程在连续3次向从设备pdcp进程发送心跳包请求消息之后，仍然没有接收到任何一个来自于从设备pdcp进程的心跳包，则可以断定从设备 pdcp进程已经掉线。
62.综上所述，当从设备pdcp进程在线的时候，本技术方案与传统的心跳保活机制一样，只需每隔20s进行一次心跳包的收发操作，因此网络资源消耗与传统的心跳保活机制相同。当从设备pdcp进程掉线的时候，传统心跳保活机制需要等待90s之后才能断定从设备pdcp进程已经掉线，而本技术方案仅需要 26s(20s 3*2s)即可断定从设备pdcp进程已经掉线。
63.本实施例克服现有心跳保活机制不能兼顾网络资源消耗和响应效率的问题。当主设备接收从设备心跳包超时的时候，主动向从设备发起询问，兼顾了网络资源消耗和响应效率，使得心跳保活机制可以在不增加网络资源消耗的情况下，大幅提高主设备发现从设备掉线事件的响应效率。
64.实施例3，如图1所示，一种高效能的心跳保活方法，包括以下具体步骤：
65.步骤一：从设备周期性地向主设备发送心跳包，发送周期为t0；
66.步骤二：主设备等待接收从设备发送的心跳包，并同步计时；
67.步骤三：主设备判断等待接收心跳包时长是否超过预设值，若未超时，则将心跳包请求次数记为0，若超时，则需进一步判断心跳包请求次数；
68.步骤四：在主设备判断心跳包请求超时后，查询心跳包请求次数是否超过心跳包请求次数上限n，若心跳包请求次数小于n，则主动向从设备发送心跳包请求消息，并将心跳包请求次数累加1；若心跳包请求次数大于n，则确定从设备已掉线。
69.步骤二中所述同步计时具体为主设备在从设备传输心跳包的同时进行计时。
70.所述主设备等待心跳包时长预设值为t0 t1，t0为从设备心跳包发送周期时间，t1为心跳包传输时长。
71.所述t0和t1根据实际应用进行调节。
72.在传统的心跳保活机制当中，如图2所示，从设备只需要周期性地向主设备发送心跳包；相应的，如图3所示，主设备也只需要被动地接收从设备发来的心跳包；当主设备发现心跳超时时长达到一定程度的时候，如图4所示，则可以断定从设备已经掉线。
73.在本发明中，从设备除了周期性地向主设备发送心跳包之外，还需要响应主设备发送来的心跳包请求消息。也就是说，从设备除了周期性地向主设备发送心跳包之外，还需要在收到主设备发来的心跳包请求消息的时候立即向主设备发送一个心跳包消息，其运行逻辑的流程图如附图5所示。
74.与之对应的，主设备也不再只是如附图4所示的流程图那样只是被动地等待心跳超时。而是在发现心跳超时时长达到从设备发送心跳包周期的时候，主动地向从设备发出心跳包请求消息，以便于快速地确认从设备当前是否在线，其运行逻辑的流程图如附图1所示。
75.简而言之，在传统的心跳保活机制当中，主设备的运行逻辑如附图3和附图 4所示，从设备的运行逻辑如附图2所示；在本发明的技术方案当中，主设备的运行逻辑如附图1和附图3所示，从设备的运行逻辑如附图2和附图5所示。
76.本实施例中，主设备为oam进程，从设备为sdap进程，定义心跳包发送周期t0为30s，心跳包传输时长上限t1为1s，心跳超时时长上限t2为90s，消息接收周期t3为0.1s，心跳包请求次数上限为3。
77.当从设备sdap进程在线时，由于从设备sdap进程会周期性地向主设备oam 进程发送心跳包，从设备sdap进程和主设备oam进程之间仅需要每隔30s进行一次心跳包的收发操作。在此情景之下，本技术方案的表现与传统心跳保活机制完全一致。
78.当从设备sdap进程掉线时主设备oam进程将在等待31s(即t0 t1)之后，发现心跳包已超时，此时的主设备oam进程将会以每秒1次的频率向从设备pdcp 进程发送心跳包请求消息。如果在此过程当中，主设备oam进程接收到了来自从设备sdap进程的心跳包，则重新回到被动等待从设备心跳包的循环当中。如果主设备oam进程在连续3次向从设备sdap进程发送心跳包请求消息之后，仍然没有接收到任何一个来自于从设备sdap进程的心跳包，则可以断定从设备 sdap进程已经掉线。
79.综上所述，当从设备sdap进程在线的时候，本技术方案与传统的心跳保活机制一
样，只需每隔30s进行一次心跳包的收发操作，因此网络资源消耗与传统的心跳保活机制相同。当从设备sdap进程掉线的时候，传统心跳保活机制需要等待90s之后才能断定从设备sdap进程已经掉线，而本技术方案仅需要 33s(30s 3*1s)即可断定从设备sdap进程已经掉线，响应效率相较传统心跳保活机制大幅提升。
80.本发明具有广泛应用价值，实施例3选取其他业务进程作为本实施例中的从设备，使oam进程可以监测sdap进程的运行状态。
81.以上显示和描述了本发明的基本原理和主要特征和本发明的优点，本行业的技术人员应该了解，本发明不受上述实施例的限制，上述实施例和说明书中描述的只是说明本发明的原理，在不脱离本发明精神和范围的前提下，本发明还会有各种变化和改进，这些变化和改进都落入要求保护的本发明范围内。本发明要求保护的范围由所附的权利要求书及其等效物界定。