CN110601914A - 监测服务器存活状态的方法及系统 - Google Patents

监测服务器存活状态的方法及系统 Download PDF

Info

Publication number
CN110601914A
CN110601914A CN201910719015.6A CN201910719015A CN110601914A CN 110601914 A CN110601914 A CN 110601914A CN 201910719015 A CN201910719015 A CN 201910719015A CN 110601914 A CN110601914 A CN 110601914A
Authority
CN
China
Prior art keywords
server
equipment
heartbeat packet
devices
heartbeat
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201910719015.6A
Other languages
English (en)
Other versions
CN110601914B (zh
Inventor
余承富
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SHENZHEN DANALE TECHNOLOGY Co Ltd
Original Assignee
SHENZHEN DANALE TECHNOLOGY Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by SHENZHEN DANALE TECHNOLOGY Co Ltd filed Critical SHENZHEN DANALE TECHNOLOGY Co Ltd
Priority to CN201910719015.6A priority Critical patent/CN110601914B/zh
Publication of CN110601914A publication Critical patent/CN110601914A/zh
Application granted granted Critical
Publication of CN110601914B publication Critical patent/CN110601914B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route

Abstract

本申请公开了一种监测服务器存活状态的方法及系统，该方法由第一设备执行，包括：监测该服务器发送的心跳包；如果该第一设备在预定时间之内未接收到该心跳包，获取其他设备的监测结果，该其他设备与该第一设备为同处于该服务器网络的设备；根据该监测结果，判定该服务器是否处于存活状态。相较于仅通过第一设备的监测结果来判断服务器的存活状态，本申请监测方法的判定准确率更高。本申请广泛应用于监测服务器的存活状态。

Description

监测服务器存活状态的方法及系统
技术领域
本申请涉及通信技术领域，尤其是涉及一种监测服务器存活状态的方法及系统。
背景技术
随着万物互联时代的到来，服务器和设备成为物联网的常见载体，在物联网的应用中会遇到判断服务器是否存活的场景，比如：批量重启服务器后，各宿主机或虚拟机是否启动成功。
为确定服务器是否存活，请参阅图1，图1是监测服务器存活状态方法的一实施例的结构示意图。该监测方法采用服务器向设备发送心跳包，如果设备在预定时间之内接收到该心跳包，则判定该服务器处于存活状态；反之，则判定该服务器处于掉线状态。
图1的监测方法不足之处在于，如果通信网络出现轻微的异常扰动，可能导致设备无法接收到心跳包，而此种情况下服务器实际处于存活状态，此类情况下，判断结果不准确。
发明内容
本申请旨在至少在一定程度上解决相关技术中的技术问题之一。为此，本申请的一个目的是提供一种监测服务器存活状态的方法及系统，能够监测服务器的存活状态，在节省设备功耗的同时，能够提高判定服务器存活状态的准确率。
本申请所采用的技术方案是：
第一方面，本申请提供一种监测服务器存活状态的方法，该方法由第一设备执行，包括：监测该服务器发送的心跳包；如果该第一设备在预定时间之内未接收到该心跳包，获取其他设备的监测结果，该其他设备与该第一设备为同处于该服务器网络的设备；根据该监测结果，判定该服务器是否处于存活状态。
其中，该心跳包的频率根据如下设备参数进行静态设定或动态调整：设备的类型、型号、重要性、寿命、电池总量以及功率、工作时长、当前电池总量、当前功耗、当前时刻、是否需要连接服务器以及通信芯片的类型和型号。
其中，该设备参数包括静态设备参数和动态设备参数；根据该静态设备参数计算该设备的第一心跳包频率，该第一心跳包频率的计算考虑各静态设备参数的权重；该第一心跳包频率的计算公式为:其中，f0表示设备20的心跳包频率，Δmi表示设备20的其中一个静态设备参数的权重，值为大于0小于1，且ηi表示该其中一个静态设备参数权重为100％时对应的心跳包频率，根据经验值设定；n表示设备20涉及的所有静态设备参数的个数总和；根据该动态设备参数计算该设备的第二心跳包频率，该第二心跳包频率的计算考虑各静态设备参数的权重和各动态设备参数的影响因子；该第二心跳包频率的计算公式为：其中f0表示第一心跳包频率，ft表示第二心跳包频率，m表示动态设备参数的总个数，Δτj表示第j个动态设备参数对心跳包频率的影响因子，数值大于0。
其中，对多个设备进行优先级打分，优先级打分的计算公式为：其中，Yi表示第i个设备的优先级分数，n表示第i个设备涉及的所有优先级影响参数的个数总和，Si表示第n个优先级影响参数的最高分值，ΔXi表示所述第n个优先级影响参数对应满分参数的比例因子；其中，优先级影响参数包括如下一项或多项参数的组合：设备与服务器之间的物理距离、设备的电池总量、设备的CPU性能以及设备的单位功耗；采用打分最高的设备作为所述第一设备。
其中，根据该监测结果，判定该服务器是否处于存活状态，包括：该其他设备为一个第二设备，如果该第二设备接收到该服务器发送的心跳包，则判定该服务器为存活状态；反之，则判定该服务器处于掉线状态；或者该其他设备为多个设备，如果该其他设备中接收到该心跳包的设备数量大于等于未接收到该心跳包的数量，则判定该服务器为存活状态；反之，则判定该服务器为掉线状态。
其中，该方法还包括：在判定该服务器为掉线状态之后，该第一设备请求与该服务器建立通信连接；如果与该服务器建立通信连接成功，则进一步判定该服务器为存活状态。
第二方面，本申请还提供一种监测服务器存活状态的装置，该装置包括：心跳包监测模块，用于监测该服务器发送的心跳包；其他设备监测结果获取模块，用于如果在预定时间之内未接收到该心跳包，获取其他设备的监测结果；服务器存活状态判定模块，用于根据该监测结果，判定该服务器是否处于存活状态。
其中，该服务器存活状态判定模块包括：第一判定单元，用于该其他设备为一个第二设备，如果该第二设备接收到该服务器发送的心跳包，则判定该服务器为存活状态；反之，则判定该服务器处于掉线状态；或者第二判定单元，用于该其他设备为多个设备，如果该其他设备中接收到该心跳包的设备数量大于等于未接收到该心跳包的数量，则判定该服务器为存活状态；反之，则判定该服务器处于掉线状态。
其中，该装置还包括：与服务器建立连接请求模块，用于在判定该服务器为掉线状态之后，向该服务器发起建立连接请求；服务器存活状态第二判定模块，用于如果与该服务器建立连接成功，则进一步判定服务器为存活状态。
其中，该装置还包括：与备用服务器建立连接请求模块，用于在与该服务器建立连接失败之后，向该备用服务器发起建立连接请求；服务器掉线状态报告模块，用于如果与该备用服务器建立连接成功，向该备用服务器报告该服务器掉线状况。
第三方面，本申请还提供一种监测服务器存活状态的系统，该系统包括：服务器、第一设备以及至少一个其他设备；该服务器用于分别向该第一设备和至少一个该其他设备发送心跳包；该第一设备和至少一个该其他设备分别监测该服务器发送的该心跳包；其中，该第一设备包括上述任一种的监测服务器存活状态的装置。
本申请采用服务器同时向两个或两个以上设备发送心跳包，如果第一设备在预定时间之内未接收到心跳包，则该第一设备获取其他设备的监测结果，该其他设备为一个第二设备，若该第二设备接收到该服务器发送的心跳包，则判定该服务器为存活状态；或者该其他设备为多个设备，若该其他设备中接收到该心跳包的设备数量大于等于未接收到该心跳包的数量，则判定该服务器为存活状态；反之，则判定该服务器处于掉线状态。相较于仅通过第一设备的监测结果来判断服务器的存活状态，本申请的监测方法判定准确率更高。
进一步地，本申请还通过获取设备的类型等静态设备参数来设定设备的心跳包频率，这样，对不同的设备设置不同的心跳包频率，例如，对设备电池寿命较短或通信芯片接收功耗消耗较大的设备发送低频率的心跳包，可以节省此类设备监测心跳包的整体功耗，延长设备的使用寿命。
进一步地，本申请还通过获取设备的运行时长和是否需要与服务器通信等动态设备参数，来调整设备的心跳包频率，可以灵活调整设备监测心跳包的整体功耗。
进一步地，本申请在初步判定服务器处于掉线状态时，还通过设备向服务器发起建立通信请求，如果设备与服务器建立通信连接成功，则判定服务器处于存活状态；反之，判定服务器处于掉线状态。可以提高判断服务器是否处于存活状态的准确率。
此外，本申请在判定服务器处于掉线状态时，通过启用备用服务器，在与该备用服务器建立通信连接之后，向备用服务器报告服务器的异常状态。可以方便维护人员知晓服务器的网络故障，快速恢复服务器的正常使用。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。
图1是已知技术监测服务器存活状态的方法的一实施例的结构示意图；
图2是本申请监测服务器存活状态的方法的一实施例的流程示意图；
图3是图1的步骤S14的一实施例的流程示意图；
图4是图1的步骤S15的一实施例的流程示意图；
图5是本申请监测服务器存活状态的方法的第二实施例的流程示意图；
图6是本申请监测服务器存活状态的方法的第三实施例的流程示意图；
图7是本申请监测服务器存活状态的方法的第四实施例的流程示意图；
图8是图7的设备的心跳包频率随时间变化的一实施例的折线示意图；
图9是本申请监测服务器存活状态的方法的第五实施例的流程示意图；
图10是本申请监测服务器存活状态的系统的第六实施例的流程示意图；
图11是本申请监测服务器存活状态的系统的一实施例的结构示意图；
图12是本申请服务器的一实施例的结构示意图；
图13是本申请监测服务器存活状态的系统的一实施例的网络结构示意图。
具体实施方式
下面，对本申请涉及的一些共同的描述进行解释，需要说明的是，这些解释并不应视为对本申请要求的保护范围的限定。
一.服务器
本申请的服务器可以为实体设备，也可以为虚拟服务器，此处不限定。
本申请的实施例中，若服务器为实体设备，优选地，服务器与设备之间进行通信可采用的通信制式包括但不限于各种近场通信制式，比如：蓝牙、近场通信(Near FieldCommunication，NFC)、ZigBee、红外数据传输(Infrared Data Association，IrDA)、无线保真(Wireless Fidelity，WiFi)等。
服务器与设备之间还可以采用各种有线或无线通信方式，有线通信方式包括但不限于：以太网、MODEM通信。无线通信通信方式包括但不限于：2G、3G、4G、5G中的任意一种。
无论采用何种通信方式，只要能够实现服务器和终端之间通信即可。
二、设备
本申请的设备包括各种类型的物联网实体设备，比如家用电器设备、智能家居设备、安防监控设备、数据采集仪表设备、计算机设备、智能终端等，在此不一一列举。
三、心跳包频率
本申请所有的“心跳包频率”指的是，服务器(包括备用服务器)向设备发送心跳包的频率。
四、通信芯片的发送功耗和接收功耗对比
实践证明，通信芯片的接收功耗一般小于发送功耗，对于某些芯片，例如WIFI芯片，其接收功耗远小于发送功耗。具体地，请参考如下表所示示例：
芯片类型 WIFI WIFI WIFI 2.4G 2.4G
芯片型号 CYW43438 Hi11315 CC3200 A7190 A7131
接收功耗 40mA 45mA 59mA 28mA 27mA
发送功耗(10dBm) 25mA
发送功耗(15dBm) 260mA 229mA
发送功耗(17dBm) 120mA
发送功耗(18dBm) 290mA 270mA
发送功耗(20dBm) 320mA 183mA
发送功耗(22dBm) 352mA
表一
基于上述表一，可以分析得出：
(一)除了型号为A7131的2.4G芯片，大部分近场通信芯片的发送功耗远大于接收功耗，例如，型号为CYW43438@15dBm的WIFI芯片，其发送功耗是接收功耗的6.5倍。
(二)不同类型的通信芯片，比如WIFI芯片和2.4G芯片，两者的发送功耗和接收功耗完全不同，且功耗差值较大。例如，型号为CYW43438@15dBm的WIFI芯片与型号为A7190@17dbmd的2.4G芯片，前者发送功耗和接收功耗均为后者发送功耗和接收功耗的2倍。
(三)同类型同型号的通信芯片在不同的功率情况下对应的发送功耗不同，比如型号为CYW43438的WIFI芯片分别工作在15dBm和20dBm时，对应的发送功耗不相同，前者为260mA，后者为320mA。
五、socket
网络上的两个程序通过一个双向的通信连接实现数据的交换，这个连接的一端称为一个socket。socket的英文原义是“孔”或“插座”。作为BSD UNIX的进程通信机制，取后一种意思。通常也称作"套接字"，用于描述IP地址和端口，是一个通信链的句柄，可以用来实现不同虚拟机或不同计算机之间的通信。在Internet上的主机一般运行了多个服务软件，同时提供几种服务。每种服务都打开一个socket，并绑定到一个端口上，不同的端口对应于不同的服务。socket正如其英文原意那样，像一个多孔插座。一台主机犹如布满各种插座的房间，每个插座有一个编号，有的插座提供220伏交流电，有的提供110伏交流电，有的则提供有线电视节目。客户软件将插头插到不同编号的插座，就可以得到不同的服务。
为了更好地理解本申请的上述目的、方案和优势，下文提供了详细描述。该详细描述通过使用框图、流程图等附图和/或示例，阐明了装置和/或方法的各种实施方式。在这些框图、流程图和/或示例中，包含一个或多个功能和/或操作。本领域技术人员将理解到：这些框图、流程图或示例内的各个功能和/或操作，能够通过各种各样的硬件、软件、固件单独或共同实施，或者通过硬件、软件和固件的任意组合实施。
下文中将参考附图并结合实施例来详细说明本申请。需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
实施例一：
请参阅图2，图2是本申请监测服务器存活状态的方法的第一实施例的流程示意图。如图2所示，该流程包括如下步骤：
S11：服务器与第一设备、第二设备分别建立通信连接；
在步骤S11中，可选地，服务器向外部设备(包括第一设备、第二设备)发送广播通信命令。其中任一设备接收到该广播命令，均可向服务器返回广播命令应答包，该广播命令应答包中包含设备的ID信息，服务器根据该广播命令应答包，确认哪些设备与服务器建立通信连接。
当然，也可以采用服务器分别向第一设备、第二设备发起通信连接请求。服务器与设备分别建立通信连接的方式具有多种。以下介绍两种常见的建立通信连接的方式。
一、服务器与设备之间通过发送握手包建立通信连接。具体地，其建立通信连接的过程包括如下步骤：
(1)服务器向设备发送握手包；
其中，该握手包符合预定的通信协议格式。
(2)设备持续接收该握手包，如果设备接收到该握手包，则说明服务器与设备成功建立通信连接。
其中，如果设备接收到一串数据包，对该数据包进行数据校验，以判定该数据包是否为该握手包。数据校验合格后，设备向服务器返回确认应答(例如：字符“ACK”)。服务器收到该确认应答，则说明服务器与设备成功建立通信连接。
二、服务器和设备通过socket建立通信连接。需要注意的是，此时，在服务器创建客户端套接字，在设备创建服务器端套接字。
套接字之间的连接过程可以分为三个步骤：服务器监听、客户端请求、连接确认。
(1)服务器监听：服务器端套接字并不定位具体的客户端套接字，而是处于等待连接的状态，实时监控网络状态。
(2)客户端请求：是指由客户端套接字提出连接请求，要连接的目标是服务器端套接字。为此，客户端套接字必须首先描述它要连接的服务器套接字，指出服务器端套接字的地址和端口号，然后就向服务器端套接字提出连接请求。
(3)连接确认：是指当服务器端套接字监听到或者说接收到客户端套接字的连接请求，它就响应客户端套接字的请求，建立一个新的线程，把服务器端套接字的描述发给客户端，一旦客户端确认了此描述，连接就建立好了。而服务器端套接字继续处于监听状态，继续接收其他客户端套接字的连接请求。
S12：服务器分别获取第一设备和第二设备的心跳包频率；
其中，本步骤的执行主体为服务器。
这里要说明的是，第一设备的心跳包频率和第二设备的心跳包频率可以相同或不相同。
在步骤S12中，可根据经验值设定设备的心跳包频率。比如，设定服务器每隔24S或30S分别向第一设备和第二设备发送一次心跳包。
可选地，在服务器中提供配置文件，以设置第一设备和第二设备的心跳包频率。也可以在服务器的应用程序中直接设定第一设备和第二设备的心跳包频率。还可以通过移动终端或手持PDA供服务器设置第一设备和第二设备的心跳包频率。
S13：服务器以预定的频率分别向第一设备、第二设备发送心跳包；
在步骤S13中，执行主体为服务器，服务器以预定的相同的频率分别向第一设备、第二设备发送心跳包，也可以以预定的第一频率向第一设备发送心跳包，和以预定的第二频率向第二设备发送心跳包。
S14：第一设备和第二设备分别监测服务器发送的心跳包。
具体地，请参阅图3，图3是本申请设备监测服务器发送的心跳包的方法的一实施例的流程示意图。步骤S14由第一设备或第二设备执行，包括如下步骤：
S141：接收心跳包；
在步骤S141中，可调用socket通信协议的read函数接收该心跳包。
S142：判断当次是否成功接收该心跳包；
其中，通过比对步骤S141接收的心跳包的数据包长度和心跳包中每个字节的数值是否符合预期值，来判断当次是否成功接收该心跳包。
例如，步骤S141接收的心跳包的数据包长度为15个字节，如果该15个字节符合预期的心跳包长度，然后判断该心跳包的数据内容是否正确，将该15个字节的每个字节的内容与预期的心跳包的各个字节的内容逐一进行比对，如果该每个字节的内容与预期的字节内容相同，则判定成功接收该心跳包；否则，判定未成功接收心跳包。
在步骤S142中，如果步骤S141接收成功，则执行步骤S144，继而执行步骤S12；反之，则执行下一步骤S143。
S143：如果当次接收失败，判断当前接收状态是否满足预设的停止接收条件；
在步骤S143中，如果当前接收状态不满足预设的停止接收条件，则返回到步骤S141，继续接收心跳包；反之，则执行步骤S144。
可选地，在步骤S141中设置一个定时器；在此步骤S143中，判断当前接收状态是否满足预设的停止接收条件为：判断当前定时器的流逝时间(或者剩余时间)是否超过(小于)预定的阈值，如果超过(小于)预定阈值，则判定停止接收；反之，则判定可继续接收。
可选地，判断当前接收状态是否满足预设的停止接收条件为：判断接收总次数是否超过预定的次数，例如，设定预定次数为50次；如果超过该预定次数，则判定停止接收；反之，则判定可继续接收。
S144：停止接收心跳包。
可以理解地，在软件程序实现上，可在循环体内，循环执行步骤S141-S143，如果在步骤S143中满足预设的停止接收条件，则中断循环，执行步骤S144。
S15:如果第一设备在预定时间之内未接收到心跳包，获取第二设备的监测结果。
具体地，请参考图4，步骤15的执行主体为第一设备，包括如下步骤：
S151:第一设备与第二设备建立通信连接；
在步骤S151中，优选地，第一设备与第二设备通过无线通信方式建立通信连接，以方便布线和安装。
其中，第一设备和第二设备可通过socket通信协议建立通信连接，或者通过其他自定义的通信协议方式建立通信连接。
在其他实施例中，本步骤S151也可以在步骤S11、或者步骤S11-S22之间执行。
其中，对多个设备进行优先级打分，优先级打分的计算公式为：其中，Yi表示第i个设备的优先级分数，n表示第i个设备涉及的所有优先级影响参数的个数总和，Si表示第n个优先级影响参数的最高分值，ΔXi表示所述第n个优先级影响参数对应满分参数的比例因子；其中，优先级影响参数包括如下一项或多项参数的组合：设备与服务器之间的物理距离、设备的电池总量、设备的CPU性能以及设备的单位功耗；采用打分最高的设备作为第一设备。
S152:在建立通信连接成功之后，第一设备向第二设备请求第二设备的监测结果；
在步骤S152中，第一设备和第二设备以预定的通信协议进行通信。
其中，第一设备向第二设备发送特定的请求命令，第二设备接收到该请求命令之后，向第一设备发送监测结果。可选地，该监测结果为整数型变量，如Result＝1,代表第二设备成功接收服务器发送的心跳包；反之，如Result＝0，代表第二设备未能接收服务器发送的心跳包。
S153:第一设备接收第二设备返回的该监测结果。
在步骤S153中，为确认该监测结果对应为第二设备，第二设备向第一设备返回的包含该监测结果的通信数据包中，还包括第二设备的ID号。
S16：第一设备根据该监测结果，判定服务器是否处于存活状态。
在步骤S16中，第一设备解析该监测结果，如果第二设备成功接收服务器发送的心跳包，则判定服务器处于存活状态，第一设备和第二设备返回到步骤S14，重新执行步骤S14-S16；反之，则判定服务器处于掉线状态。
在本实施例中，采用两个设备分别接收服务器发送的心跳包，若第一设备在预定的时间内未接收到服务器发送的心跳包时，第一设备向第二设备请求第二设备的监测结果，若第二设备在预定的时间之内也未接收到服务器发送的心跳包，则判定服务器处于掉线状态。相较于仅依据第一设备是否接收到服务器的心跳包，来判定服务器的存活状态。本实施例的判定方法可进一步提高判定的准确率。
实施例二：
请参阅图5，图5是本申请监测服务器存活状态的方法的第二实施例的流程示意图。本实施例与实施例一的区别在于，还通过获取第三设备的监测结果。如图5所示，该流程包括如下步骤：
S21：第一设备、第二设备以及第三设备分别监测服务器发送的心跳包；
可以理解地，在步骤S21之前，省略了如下步骤：第一设备、第二设备以及第三设备分别与服务器建立通信连接；服务器分别获取第一设备、第二设备以及第三设备的心跳包频率；服务器以预定的频率分别向第一设备、第二设备以及第三设备发送心跳包。
在步骤S21中，设备监测服务器发送的心跳包的方法与实施例一的步骤S14相同，在此不作赘述。
S22：如果第一设备在预定时间之内未接收到心跳包，分别获取第二设备和第三设备的监测结果；
在步骤S22中，第一设备获取第二设备或第三设备的监测结果的方法与实施例一的步骤S15相同，在此不作赘述。
S23：第一设备根据该监测结果，判定服务器是否处于存活状态。
在步骤S23中，如果第二设备和第三设备均未监测到心跳包，则第一设备判定服务器处于掉线状态；如果第二设备或第三设备中的任一设备监测到心跳包，则第一设备判定服务器处于存活状态。
在其他实施例中，还可以采用三个以上的设备同时监测服务器的心跳包，如果第一设备在预定的时间内未监测到心跳包，则第一设备获取其他设备的监测结果，如果其他设备中接收到心跳包的设备数量大于等于未接收到心跳包的数量，则判定服务器为存活状态；反之，则判定服务器为掉线状态。
在本实施例中，采用三个及更多设备同时监测服务器的心跳包，这样，通过多个设备的监测结果来反应服务器的存活状态，相较于实施例一中仅通过两台设备的监测结果来反应服务器的存活状态，本实施例监测方法的判定准确率更高。
实施例三：
请参阅图6，图6是本申请监测服务器存活状态的方法的第三实施例的流程示意图。与服务器连接的多个设备可以是不同类型的，例如可以包括摄像头，电视机，地下水表检测器等，这些设备的功能不同，工作场景工作模式不同，设备的及时反应的需求也是不一样的，因此，不同的设备可以设定不同的心跳包频率。本实施例与实施例一的区别在于，通过获取设备的静态设备参数，来设置设备的心跳包频率。
如图6所示，该方法包括如下步骤：
S31:服务器与第一设备、第二设备分别建立通信连接；
其中，步骤S11与实施例一的步骤S11相同。
S32:服务器分别获取第一设备、第二设备的静态设备参数，根据第一设备、第二设备的静态设备参数，分别计算并设定第一设备、第二设备的心跳包频率；
其中，静态设备参数包括：设备的类型、型号、重要性、寿命、电池总量、功率以及通信芯片的类型和型号等。
步骤S32的实施方式可以为：
(1)服务器获取第一设备或第二设备的全部静态设备参数。比如，服务器与第一设备、第二设备首次建立通信连接时，发送特定的通信命令给第一设备、第二设备；第一设备、第二设备接收到特定的命令之后，向服务器发送自身的静态设备参数。
(2)服务器获取第一设备或第二设备的设备类型和型号，然后根据第一设备或第二设备的设备类型和型号，在服务器的数据库中查询第一设备或第二设备的其他静态设备参数，比如通信芯片的类型和型号、设备的重要性、寿命、电池总量以及功率等。
这里要说明的是，服务器也可以无需或不直接与设备进行通信，以获取设备的静态设备参数。比如，在服务器中通过应用软件手动配置设备的设备类型和型号，或者通过读取配置文件获取设备的设备类型和型号，然后在数据库中根据该设备类型和型号查询设备的其他静态设备参数；甚至，服务器还可以通过接收来自其他移动终端的通信数据，以获取设备的静态设备参数。
优选地，通过经验值公式计算第一设备或第二设备的心跳包频率。该经验值公式考虑各个静态设备参数的权重。
为方便理解，该经验值公式可以表示如下：
，
其中，f0表示设备的心跳包频率，Δmi表示设备的其中一个静态设备参数的权重，值为大于0小于1，且满足：；
ηi表示该其中一个静态设备参数权重为100％时对应的心跳包频率，根据经验值设定；n表示设备20涉及的所有静态设备参数的个数总和。
根据前述的通信芯片的功耗表(表一)可以得出，不同类型或型号的通信芯片的接收功耗并不相同，因此有必要对不同的通信芯片设置不同的心跳包频率，例如，对于接收功耗仍然消耗较大的通信芯片，设置低频率的心跳包，这样有利于降低设备工作过程中的整体功耗。
如下具体说明其他静态设备参数对于设置设备的心跳包频率的影响。
(1)设备的重要性。例如，有些不常用的设备，可以降低其心跳包频率。
(2)设备的寿命。为延长设备的使用寿命，对设备寿命较短的设备，有必要降低其心跳包频率。
(3)设备的电池总量。为延长设备的使用寿命，对电池总量较少的设备，有必要降低其心跳包频率。
(4)设备的功率。为降低设备的功耗，对功耗较大的设备，有必要降低其心跳包频率。
S33-S36：分别同实施例一的步骤S13-S16。
在本实施例中，根据设备的静态设备参数来计算设备的心跳包频率，该静态设备参数与设备的功耗或者使用寿命密切关联，这样，对不同的设备设置不同的心跳包频率，例如，对设备电池寿命较短或通信芯片接收功耗消耗较大的设备发送低频率的心跳包，可以节省此类设备监测心跳包的整体功耗，延长设备的使用寿命。
实施例四：
请参阅图7，图7是本申请监测服务器存活状态的方法的第四实施例的流程示意图。本实施例与实施例三的区别在于，进一步地，在服务器向设备发送固定频率的心跳包间隔一段时间之后，实时获取设备的动态设备参数，并根据该动态设备参数调整设备的心跳包频率。
如图7所示，该方法包括如下步骤：
S41：同实施例三的步骤S31；
S42：服务器分别获取第一设备、第二设备的静态设备参数，根据第一设备、第二设备的静态设备参数，分别计算并设定第一设备、第二设备的第一心跳包频率；
其中，本步骤S42与实施例三的步骤S32相同，该第一心跳包频率即为步骤S32中的心跳包频率，本步骤称之为第一心跳包频率。
S43：服务器以第一心跳包频率分别向第一设备、第二设备发送心跳包；
其中，步骤S43与实施例三的步骤S33相同。
S44：在设备20运行一段时间之后，服务器实时获取设备20的动态设备参数，根据该静态设备参数和该动态设备参数计算设备20的第二心跳包频率；
在步骤S44中，该动态设备参数包括：设备的运行时长、当前电池总量、当前功耗、当前时刻以及是否需要连接服务器等。
可选地，服务器每隔一段时间自动获取设备的动态设备参数。比如，在服务器的应用程序中设定每隔2小时获取设备的动态设备参数；或者通过配置文件或手绘曲线图方式设置获取动态设备参数的时间间隔。
可选地，服务器上设置手动按钮，点击该手动按钮，服务器就会即时获取设备的动态设备参数，方便维护人员随时进行调整设备的心跳包频率。
在步骤S44中，将动态设备参数加入到心跳包频率计算公式中。
可选地，计算第二心跳包频率的公式如下：
其中，f0表示第一心跳包频率，ft表示第二心跳包频率，m表示动态设备参数的总个数，Δτj表示第j个动态设备参数对心跳包频率的影响因子，数值大于0。
以下具体介绍各动态设备参数及其对应的对心跳包频率的影响因子。
(1)当前功耗。可选地，若设备当前功耗大于设备额定功耗，则影响因子＝额定功耗/当前功耗。
(2)当前电池电量。可选地，若设备当前电池电量小于预定的阈值，则影响因子＝当前电池电量/电池电量阈值。
(3)运行时长。可选地，若设备运行时长超过预定的阈值，则影响因子＝设备运行时长阈值/当前设备运行时长。
(4)当前时刻。可选地，根据设备的工作特点，预先设定该影响因子。
(5)是否连接服务器，其对应的影响因子τ为1或0，即设备不需要连接服务器，则将τ置为0，即服务器对设备不发送心跳包；反之，则将τ置为1，即服务器对设备发送心跳包。该场景应用在：比如设备类型为电能量采集终端，此类设备只需要在特定的时间段(例如：每天的23:00-24:00)与服务器通信(例如：电能量采集终端向服务器上报一天的历史数据记录)。
S45：服务器以第二心跳包频率分别向第一设备、第二设备发送心跳包；
其中，步骤S45发送心跳包的方法与实施例的步骤S43发送心跳包的方法相同，不同之处在于，发送心跳包的频率不相同。
S46：同实施例三的步骤S34。
S47：同实施例三的步骤S35。
S48：同实施例三的步骤S36。
可以理解地，在执行步骤S43之后，循环执行步骤S44-步骤S48。
请参阅图8，图8是第一设备(某电能量采集器)的心跳包频率随时间变化的一实施例的折线示意图。如图8所示，第一设备的心跳包频率在20：00-22:00时间段，对应的数值为4次/小时；在22:00-24:00时间段，该时间段为设备20准备上报数据时间段，因此为确保设备20的工作效率，相应减少设备20的心跳包频率，将心跳包频率设置为3次/小时；在24:00-4:00时间段，该时间段需要向服务器上报设备20当天的电能量和事件记录等数据，为确保服务器和设备20通信连接不中断，相应提高设备20的心跳包频率，将该数值设置为6次/小时。同样地，也可以设置第二设备的心跳包频率随时间变化。
在本实施例中，通过获取设备的运行时长和是否需要与服务器通信等动态设备参数，来定时或不定时调整设备的心跳包频率，相较于实施例三的方法，本实施例可以灵活调整设备的心跳包频率，从而灵活调整监测心跳包的整体功耗，有利于进一步降低设备工作过程中的功耗，提高设备的使用寿命。
实施例五：
请参阅图9，图9是本申请监测服务器存活状态的方法的第五实施例的流程示意图。如图9所示，本实施例与实施例一的区别在于：在判定服务器处于掉线状态时，进一步地，设备向服务器主动发送建立通信连接请求，通过是否能够与服务器建立通信连接，来判定服务器是否处于存活状态。该方法包括如下步骤：
S51-S56：分别同实施例一的步骤S11-S16。
S57：在判定服务器为掉线状态之后，第一设备向服务器发起建立连接请求。
在步骤S57中，可选地，此时在第一设备创建客户端套接字，在服务器创建服务器端套接字。具体地，通过套接字建立通信连接的方法在实施例一的步骤S11中已详细阐述，在此不再赘述。
S58：如果与服务器建立通信连接成功，第一设备则判定服务器为存活状态。
在步骤S58中，如果第一设备成功收到服务器的连接请求应答回复，则判定与服务器建立通信连接成功。
其中，在判定服务器为存活状态之后，结束步骤S58，第一设备返回重新执行步骤S54-S58。
在本实施例中，相较于实施例一，通过步骤S57和步骤S58进一步判定服务器是否处于存活状态，有利于提高设备20判定服务器是否处于存活状态的准确率。可以理解地，也可以在实施例二或实施例三或实施例四的最后一个步骤之后，执行本实施例的步骤S57和步骤S58的方法。
实施例六：
请参阅图10，图10是本申请监测服务器存活状态的方法的第六实施例的流程示意图。本实施例与实施例五的区别在于：若判定服务器处于掉线状态，进一步地，第一设备与备用服务器建立通信连接，并向备用服务器报告服务器处于掉线状态。如图10所示，该方法包括如下步骤
S61-S68：分别同实施例一的步骤S11-S16。
S69：在与服务器建立通信连接失败之后，第一设备向备用服务器发起建立连接请求；如果与备用服务器建立连接成功，第一设备向备用服务器报告服务器处于掉线状态。
在步骤S69中，第一设备向备用服务器发起建立连接请求的方法与第一设备向服务器发起建立请求的方法相同，在此不再赘述。
在步骤S69中，第一设备除了向备用服务器报告服务器处于掉线的状态之外，还可以向备用服务器报告第一设备的异常通信数据记录。优选地，该异常通信数据记录采用日志文件形式记录服务器与第一设备之间收发心跳包的异常数据信息。第一设备将该日志文件上传到备用服务器。采用日志文件方式的好处是方便在备用服务器上保存异常数据信息。
优选地，备用服务器收到服务器处于掉线的状态时，以声音信号或者光信号方式发出告警提示信息，例如，采用扬声器发出提示声音，提醒维护人员进行检查。
这里要说明的是，备用服务器的数量不作限定，如果第一设备无法与第一台备用服务器建立连接，则第一设备可以与第二备用服务器建立连接。可选地，备用服务器的软硬件配置与服务器的软硬件配置相同。
在本实施例中，如果确定服务器处于掉线状态，那么服务器与第一设备之间无法通信，第一设备通过与备用服务器建立通信连接，以使第一设备保持正常工作。
进一步地，本实施例的第一设备还可以向备用服务器报告服务器的掉线状态，以方便维护人员获知服务器出现故障。
此外，本实施例可以将第一设备的日志记录发送至备用服务器，这样，在备用服务器可根据日志记录，分析服务器的掉线故障原因，从而快速排除服务器的故障，重新启动服务器正常工作。
实施例七：
请参阅图11，图11是本申请监测服务器存活状态的系统的一实施例的结构示意图。如图11所示，该系统包括服务器10、第一设备20以及第二设备40。
服务器10包括通信连接建立模块11、心跳包频率获取模块12以及心跳包发送模块13。第一设备20包括心跳包监测模块21、其他设备监测结果获取模块22以及服务器存活状态判定模块23。第二设备40包括心跳包监测模块41和监测结果发送模块42。
通信连接建立模块11用于分别与第一设备20和第二设备40建立通信连接。
心跳包频率获取模块12，用于分别获取第一设备20和第二设备40的心跳包频率。
心跳包发送模块13，用于基于该心跳包频率向第一设备20和第二设备40分别发送心跳包。
心跳包监测模块21，用于第一设备20监测服务器10发送的心跳包；
其他设备监测结果获取模块22，用于如果在预定时间之内未接收到该心跳包，第一设备20获取其他设备的监测结果；
服务器存活状态判定模块23，用于第一设备20根据该监测结果，判定该服务器是否处于存活状态。优选地，服务器存活状态判定模块23包括：第一判定单元和第二判定单元。第一判定单元用于该其他设备为一个第二设备，如果该第二设备接收到所述服务器发送的心跳包，则判定该服务器为存活状态；反之，则判定该服务器处于掉线状态。第二判定单元，用于该其他设备为多个设备，如果该其他设备中接收到心跳包的设备数量大于等于未接收到心跳包的数量，则判定该服务器为存活状态；反之，则判定该服务器处于掉线状态。
心跳包监测模块41，用于第二设备40监测服务器10发送的心跳包。
监测结果发送模块42，用于第二设备40向第一设备20发送心跳包监测结果。
具体地，该系统各模块的工作方法在实施例一中已详细阐述，在此不再赘述。
实施例八：
请参阅图12，图12是本申请监测服务器存活状态的系统的一实施例的结构示意图。如图12所示，该系统包括服务器10、第一设备20以及第二设备40。该实施例与实施例七的区别在于，服务器10包括：第一心跳包频率计算模块12、第一心跳包发送模块13、第二心跳包频率计算模块以及第二心跳包发送模块15。
第一心跳包频率计算模块12用于分别获取第一设备20和第二设备40的静态设备参数，并根据该静态设备参数分别计算第一设备20和第二设备40的第一心跳包频率。第一心跳包发送模块13用于分别向第一设备20和第二设备40以该第一心跳包频率发送心跳包。
第二心跳包频率计算模块14用于在第一设备20运行一段时间之后，分别实时获取第一设备20和第二设备40的动态设备参数，根据该静态设备参数和该动态设备参数分别计算第一设备20和第二设备40的第二心跳包频率。第二心跳包发送模块15用于分别向第一设备20和第二设备40以该第二心跳包频率发送心跳包。
具体地，第一心跳包频率计算模块12、第一心跳包发送模块13、第二心跳包频率计算模块以及第二心跳包发送模块15的工作方法在实施例三或实施例四中已详细阐述。
实施例九：
请参阅图13，图13是本申请监测服务器存活状态的系统的另一实施例的网络结构示意图。如图13所示，该监测系统包括服务器10、第一设备20、备用服务器30以及第二设备40。
其中，第一设备20分别与服务器10、备用服务器30连接。第二设备40分别与服务器10、备用服务器30连接。
本监测系统在工作时，首先，使服务器10分别与第一设备20、第二设备40建立通信连接，服务器10分别向第一设备20、第二设备40发送心跳包，第一设备20如果在预定的时间之内接收到该心跳包，则判定服务器10处于存活状态；反之，则判定服务器10可能处于掉线状态，此时第一设备20与第二设备40进行通信，第一设备20向第二设备40请求第二设备40的监测结果，如果第二设备40成功接收到心跳包，则说明服务器10处于存活状态；反之，则说明服务器20可能处于掉线状态，第一设备20向服务器10发起建立通信连接请求，如果与服务器10无法建立通信连接，则说明服务器10处于掉线状态，此时，第一设备20向备用服务器30发起建立通信连接请求，如果与备用服务器30建立通信连接成功，则向备用服务器30报告服务器10处于掉线状态，以提示维护人员对服务器10进行检查维修。
综上，本申请提供一种检测服务器存活状态的方法及系统，可实现监测服务器的存活状态。本申请通过采用服务器向多个设备发送心跳包，通过结合多个设备的监测结果，判定服务器是否处于存活状态；相较于仅通过一个设备来判定服务器是否处于存活状态，本申请的监测方法判定准确率更高。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请的实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然，本领域的技术人员可以对本申请的实施例进行各种改动和变型而不脱离本申请的实施例的精神和范围。这样，倘若本申请的实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种监测服务器存活状态的方法，其特征在于，包括：
采用多个设备同时监测所述服务器发送的心跳包，多个所述设备为同处于服务器网络的设备；
根据多个所述设备的监测结果，判定所述服务器是否处于存活状态。
2.根据权利要求1所述的方法，其特征在于，多个所述设备包括第一设备和其他设备，所述根据多个所述设备的监测结果，判定所述服务器是否处于存活状态，包括：
如果在预定时间之内未接收到所述心跳包，采用第一设备获取其他设备的监测结果；
根据所述其他设备的监测结果，判定所述服务器是否处于存活状态。
3.根据权利要求2所述的方法，其特征在于，所述根据所述其他设备的监测结果，判定所述服务器是否处于存活状态，包括：
其他设备为一个第二设备，如果所述第二设备接收到所述服务器发送的心跳包，则判定所述服务器为存活状态；反之，则判定所述服务器处于掉线状态；或者
所述其他设备为多个设备，如果所述其他设备中接收到所述心跳包的设备数量大于等于未接收到所述心跳包的数量，则判定所述服务器为存活状态；反之，则判定所述服务器为掉线状态。
4.根据权利要求1至3任意一项所述的方法，其特征在于，所述心跳包的频率根据如下设备参数进行静态设定或动态调整：设备的类型、型号、重要性、寿命、电池总量以及功率、工作时长、当前电池总量、当前功耗、当前时刻、是否需要连接服务器以及通信芯片的类型和型号。
5.根据权利要求4所述的方法，其特征在于，所述心跳包的频率包括第一心跳包频率和第二心跳包频率，所述设备参数包括静态设备参数和动态设备参数；
所述静态设备参数包括：类型、型号、重要性、寿命、电池总量、功率以及通信芯片的类型和型号，所述动态设备参数包括：工作时长、当前电池总量、当前功耗、当前时刻以及是否需要连接服务器；
所述第一心跳包频率根据所述静态设备参数计算而定，所述第一心跳包频率的计算考虑各静态设备参数的权重；
所述第二心跳包频率根据所述动态设备参数间隔调整，所述第二心跳包频率的计算考虑各静态设备参数的权重和各动态设备参数的影响因子。
6.根据权利要求5所述的方法，其特征在于，所述第一心跳包频率的计算公式为:其中，f0表示设备的心跳包频率，Δmi表示设备的其中一个静态设备参数的权重，值为大于0小于1，且ηi表示该其中一个静态设备参数权重为100％时对应的心跳包频率，根据经验值设定；n表示设备涉及的所有静态设备参数的个数总和；
所述第二心跳包频率的计算公式为：其中f0表示第一心跳包频率，ft表示第二心跳包频率，m表示动态设备参数的总个数，Δτj表示第j个动态设备参数对心跳包频率的影响因子，数值大于0。
7.根据权利要求2所述的方法，其特征在于，还包括：
对多个所述设备进行优先级打分，所述优先级打分的计算公式为：其中，Yi表示第i个设备的优先级分数，n表示第i个设备涉及的所有优先级影响参数的个数总和，Si表示第n个优先级影响参数的最高分值，ΔXi表示所述第n个优先级影响参数对应满分参数的比例因子；其中，所述优先级影响参数包括如下一项或多项参数的组合：所述设备与所述服务器之间的物理距离、所述设备的电池总量、所述设备的CPU性能以及所述设备的单位功耗；
采用打分最高的设备作为所述第一设备。
8.根据权利要求2所述的方法，其特征在于，还包括：
在判定所述服务器为掉线状态之后，采用所述第一设备与所述服务器建立通信连接；
如果所述第一设备与所述服务器建立通信连接成功，则判定所述服务器为存活状态。
9.根据权利要求8所述的方法，其特征在于，所述第一设备与所述服务器建立通信连接失败之后，还包括：
采用所述第一设备向备用服务器发起建立连接请求；
如果所述第一设备与所述备用服务器建立连接成功，则向所述备用服务器报告所述服务器掉线状况。
10.一种监测服务器存活状态的系统，其特征在于，包括：服务器和多个设备；
所述服务器用于分别向多个所述设备发送心跳包；
多个所述设备用于分别监测所述服务器发送的所述心跳包；
其中，多个所述设备用于执行根据权利要求1至9任意一项所述的方法。
CN201910719015.6A 2019-08-05 2019-08-05 监测服务器存活状态的方法及系统 Active CN110601914B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910719015.6A CN110601914B (zh) 2019-08-05 2019-08-05 监测服务器存活状态的方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910719015.6A CN110601914B (zh) 2019-08-05 2019-08-05 监测服务器存活状态的方法及系统

Publications (2)

Publication Number Publication Date
CN110601914A true CN110601914A (zh) 2019-12-20
CN110601914B CN110601914B (zh) 2022-11-22

Family

ID=68853613

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910719015.6A Active CN110601914B (zh) 2019-08-05 2019-08-05 监测服务器存活状态的方法及系统

Country Status (1)

Country Link
CN (1) CN110601914B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111988203A (zh) * 2020-09-03 2020-11-24 深圳壹账通智能科技有限公司 节点选举方法、装置及存储介质

Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2551206A1 (en) * 2006-06-23 2007-12-23 Research In Motion Limited Secure wireless heartbeat
CN101917437A (zh) * 2010-08-20 2010-12-15 迈普通信技术股份有限公司 基于sip的用户离线检测方法以及sip用户状态检测系统
CN102447631A (zh) * 2011-12-28 2012-05-09 华为终端有限公司 一种心跳连接方法，相关装置以及系统
CN103248504A (zh) * 2012-02-06 2013-08-14 上海软智信息科技有限公司 一种集群节点匹配方法、集群通信模块、设备及系统
CN103701667A (zh) * 2013-12-27 2014-04-02 乐视网信息技术（北京）股份有限公司 服务器的心跳的监控方法、装置及系统
CN103795554A (zh) * 2012-10-29 2014-05-14 华为技术有限公司 一种管理终端状态的方法，装置和系统
US20150113315A1 (en) * 2010-10-28 2015-04-23 Juniper Networks, Inc. Switch provided failover
CN105072168A (zh) * 2015-07-28 2015-11-18 中国石油集团川庆钻探工程有限公司地球物理勘探公司 对三维层位数据进行构造解释的方法
CN105610913A (zh) * 2015-12-22 2016-05-25 用友网络科技股份有限公司 通信网络中长连接的心跳保活方法及装置
CN106487864A (zh) * 2015-09-02 2017-03-08 华为终端（东莞）有限公司 数据连接的建立方法、服务端及移动终端
CN106571973A (zh) * 2016-09-28 2017-04-19 杭州鸿雁智能科技有限公司 心跳包超时管理方法及系统
CN108173709A (zh) * 2017-12-19 2018-06-15 广州视源电子科技股份有限公司 保活长连接方法、装置、终端设备及存储介质
CN109040277A (zh) * 2018-08-20 2018-12-18 北京奇虎科技有限公司 一种服务器的远程监控方法及装置
CN109218789A (zh) * 2018-11-20 2019-01-15 北京千丁互联科技有限公司 广告机同步播放系统及方法
CN109495312A (zh) * 2018-12-05 2019-03-19 广州鼎甲计算机科技有限公司 基于仲裁盘和双链路的高可用集群的实现方法和系统
CN109766324A (zh) * 2018-12-14 2019-05-17 东软集团股份有限公司 分布式锁的控制方法、装置、可读存储介质及电子设备
CN109905259A (zh) * 2017-12-08 2019-06-18 中国电信股份有限公司 通信连接维持方法、系统和相关设备

Patent Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2551206A1 (en) * 2006-06-23 2007-12-23 Research In Motion Limited Secure wireless heartbeat
CN101917437A (zh) * 2010-08-20 2010-12-15 迈普通信技术股份有限公司 基于sip的用户离线检测方法以及sip用户状态检测系统
US20150113315A1 (en) * 2010-10-28 2015-04-23 Juniper Networks, Inc. Switch provided failover
CN102447631A (zh) * 2011-12-28 2012-05-09 华为终端有限公司 一种心跳连接方法，相关装置以及系统
CN103248504A (zh) * 2012-02-06 2013-08-14 上海软智信息科技有限公司 一种集群节点匹配方法、集群通信模块、设备及系统
CN103795554A (zh) * 2012-10-29 2014-05-14 华为技术有限公司 一种管理终端状态的方法，装置和系统
CN103701667A (zh) * 2013-12-27 2014-04-02 乐视网信息技术（北京）股份有限公司 服务器的心跳的监控方法、装置及系统
CN105072168A (zh) * 2015-07-28 2015-11-18 中国石油集团川庆钻探工程有限公司地球物理勘探公司 对三维层位数据进行构造解释的方法
CN106487864A (zh) * 2015-09-02 2017-03-08 华为终端（东莞）有限公司 数据连接的建立方法、服务端及移动终端
CN105610913A (zh) * 2015-12-22 2016-05-25 用友网络科技股份有限公司 通信网络中长连接的心跳保活方法及装置
CN106571973A (zh) * 2016-09-28 2017-04-19 杭州鸿雁智能科技有限公司 心跳包超时管理方法及系统
CN109905259A (zh) * 2017-12-08 2019-06-18 中国电信股份有限公司 通信连接维持方法、系统和相关设备
CN108173709A (zh) * 2017-12-19 2018-06-15 广州视源电子科技股份有限公司 保活长连接方法、装置、终端设备及存储介质
CN109040277A (zh) * 2018-08-20 2018-12-18 北京奇虎科技有限公司 一种服务器的远程监控方法及装置
CN109218789A (zh) * 2018-11-20 2019-01-15 北京千丁互联科技有限公司 广告机同步播放系统及方法
CN109495312A (zh) * 2018-12-05 2019-03-19 广州鼎甲计算机科技有限公司 基于仲裁盘和双链路的高可用集群的实现方法和系统
CN109766324A (zh) * 2018-12-14 2019-05-17 东软集团股份有限公司 分布式锁的控制方法、装置、可读存储介质及电子设备

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
LINGYUN REN，ET AL.，: ""Noncontact Multiple Heartbeats Detection and Subject Localization Using UWB Impulse Doppler Radar"", 《IEEE MICROWAVE AND WIRELESS COMPONENTS LETTERS 》 *
曹旭东，: ""基于BANS的云平台监控系统的设计与实现"", 《中国优秀硕士学位论文全文数据库 (信息科技辑)》 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111988203A (zh) * 2020-09-03 2020-11-24 深圳壹账通智能科技有限公司 节点选举方法、装置及存储介质

Also Published As

Publication number Publication date
CN110601914B (zh) 2022-11-22

Similar Documents

Publication Publication Date Title
CN110445682B (zh) 监测联网节点存活状态的方法、服务器、设备及系统
CN110445683B (zh) 服务器、设备、监测服务器存活状态的方法及系统
CN101488887B (zh) 监控方法和监控装置
CN108092847B (zh) 一种电力lte无线终端远程在线监控方法
WO2018201997A1 (zh) 一种家电故障统计方法及装置
CN104796464A (zh) 一种基于modbus的多协议转换警情信息远程传输系统和方法
CN210405371U (zh) 一种基于物联网的空压智能运维系统
US10945143B2 (en) Data transmission method, apparatus, and system
CN108989463B (zh) 一种数据处理方法和装置
CN110809262B (zh) 一种基于coap协议的物联网设备运维管理方法
CN110601914B (zh) 监测服务器存活状态的方法及系统
CN113765743B (zh) 智能网关工作状态监控方法
CN110166322B (zh) 一种计量自动化终端的检测方法和相关装置
CN111835578B (zh) 信息传输管理方法、信息传输管理装置及可读存储介质
CN115048274B (zh) 一种基于大数据的运维系统
CN209166518U (zh) 一种基于无线传感技术的变电站机房环境在线监控系统
CN115378841B (zh) 设备接入云平台状态的检测方法及装置、存储介质、终端
CN106385384B (zh) 一种报文发送方法及网络设备
CN114399891A (zh) 基于物联网的机房智能监控运维系统及方法
CN112073472A (zh) 一种计数器软清零处理方法
CN112671895A (zh) 设备的控制方法、装置、终端和计算机可读存储介质
CN111343700A (zh) 无线传感网络通信方法
CN113645108B (zh) 一种智能家居设备监控系统及方法
CN115277794B (zh) 一种基于多种协议的智能数据采集方法和系统
CN113595555B (zh) 能耗数据预测编码压缩采集方法及系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant