CN110445683B

CN110445683B - Server, equipment, method and system for monitoring survival state of server

Info

Publication number: CN110445683B
Application number: CN201910718612.7A
Authority: CN
Inventors: 余承富
Original assignee: Shenzhen Danale Technology Co ltd
Current assignee: Shenzhen Danale Technology Co ltd
Priority date: 2019-08-05
Filing date: 2019-08-05
Publication date: 2022-11-25
Anticipated expiration: 2039-08-05
Also published as: CN110445683A

Abstract

The application discloses a server, equipment, a method and a system for monitoring the survival state of the server. The method for monitoring the survival state of the server comprises the following steps: the server establishes communication connection with the equipment, acquires the heartbeat packet frequency of the equipment, and sends a heartbeat packet to the equipment based on the heartbeat packet frequency; the equipment monitors the heartbeat packet sent by the server, and if the heartbeat packet is received within the preset time, the server is judged to be in a survival state. Compared with the monitoring method in the prior art that whether the server is in a survival state or not is judged by sending the heartbeat packet to the server through the equipment, the equipment only needs to receive data in the process of monitoring the heartbeat packet without sending the data, so that the equipment only needs to consume the receiving power consumption and does not need to consume the sending power consumption, the whole power consumption of the equipment is saved, and the service life of the equipment is prolonged. The method and the device are widely applied to monitoring the survival state of the server.

Description

Server, equipment, method and system for monitoring survival state of server

Technical Field

The present application relates to the field of communications technologies, and in particular, to a server, a device, and a method and a system for monitoring a server survival status.

Background

With the advent of the world of everything interconnection, servers and devices become common carriers of the internet of things, and scenes for judging whether the servers survive are encountered in the application of the internet of things, such as: and after restarting the servers in batch, whether each host machine or each virtual machine is started successfully or not.

Referring to fig. 1, to determine whether a server is alive, fig. 1 is a schematic structural diagram of an embodiment of a method for monitoring an alive state of a server in the prior art. As shown in fig. 1, in the prior art, a heartbeat packet is sent to a server periodically or aperiodically by a device, and if a plurality of preset heartbeat packet replies are continuously lost, the device determines that the server is offline. However, in practice, it is found that the power consumption of the device for continuously sending the heartbeat packet is large, the service time of a battery of the device is greatly shortened, and the battery of part of devices cannot be replaced, so that the service life of the device is directly influenced by the power consumption of the device.

Disclosure of Invention

The present application is directed to solving, at least to some extent, one of the technical problems in the related art. Therefore, an object of the present application is to provide a server, a device, and a method and a system for monitoring a server survival status, which can monitor the server survival status, and simultaneously reduce the power consumption of the device and prolong the service life of the device.

The technical scheme adopted by the application is as follows:

in a first aspect, the present invention provides a method for monitoring server survival status, the method being performed by a server and comprising: establishing a communication connection with a device; acquiring the heartbeat packet frequency of the equipment; and sending the heartbeat packet to the equipment based on the heartbeat packet frequency.

In a second aspect, the present invention provides a method of monitoring server survival status, performed by a device in communication with a server, the method comprising: monitoring data sent by the server, and judging whether the data is the heartbeat packet or not; if the heartbeat packet is received within the predetermined time, the server is determined to be alive.

In a third aspect, the present invention provides a server, comprising: the communication connection establishing module is used for establishing communication connection with the equipment; the heartbeat packet frequency acquisition module is used for acquiring the heartbeat packet frequency of the equipment; and the heartbeat packet sending module is used for sending a heartbeat packet to the equipment based on the heartbeat packet frequency.

In a fourth aspect, the present invention provides an apparatus comprising: the heartbeat packet monitoring module is used for monitoring the data sent by the server and judging whether the data is the heartbeat packet or not; and the server survival state judging module is used for judging whether the server is in a survival state or not according to whether the heartbeat packet is received within the preset time or not.

In a fifth aspect, a server is provided, which includes: a communication module comprising a transmitter and a receiver, the communication module for establishing a communication connection with the device; a processor for obtaining a heartbeat packet frequency of a device; the transmitter is further configured to send a heartbeat packet to the device based on the heartbeat packet frequency.

In a sixth aspect, the present invention provides an apparatus comprising: the receiver is used for receiving the heartbeat packet sent by the server; and the processor is used for judging that the server is in a survival state if the heartbeat packet is received.

In a seventh aspect, the present invention provides a system for monitoring server survival status, the system comprising: the server according to any of the above and the device according to any of the above, the system further comprising a backup server; the equipment is also used for initiating a connection establishment request to the standby server after the connection establishment with the server fails; and if the connection establishment with the standby server is successful, reporting the server disconnection condition to the standby server.

The server is adopted to send the heartbeat packet to the equipment, and whether the equipment receives the heartbeat packet is judged to judge whether the server is in a survival state; compared with the prior art that equipment is adopted to send a heartbeat packet to a server and receive a heartbeat packet reply returned by the server to judge whether the server is in a survival state or not; the equipment of this application only need receive data at the in-process of monitoring heartbeat package, need not send data, therefore equipment only need consume and receive the consumption, need not to consume and send the consumption, is favorable to saving the whole consumption of equipment, prolongs the life of equipment. And for most devices, the receiving power consumption is far less than the transmitting power consumption, and the overall power consumption of the device is further saved.

Further, this application still sets for the heartbeat package frequency of equipment through static equipment parameters such as the type of acquireing equipment, like this, sets up different heartbeat package frequencies to different equipment, for example, to equipment battery life shorter or communication chip receive the equipment that power consumption is great and send the heartbeat package of low frequency, can save the whole consumption of this kind of equipment monitoring heartbeat package, the life of extension equipment.

Furthermore, the heartbeat package frequency of the equipment is adjusted by acquiring the running time of the equipment and whether dynamic equipment parameters such as communication with the server are needed or not, so that the overall power consumption of the equipment for monitoring the heartbeat package can be flexibly adjusted.

Further, when the server is preliminarily judged to be in the offline state, a communication establishing request is sent to the server through the equipment, and if the equipment and the server establish communication connection successfully, the server is judged to be in the survival state; otherwise, the server is judged to be in the offline state. The accuracy of judging whether the server is in the survival state can be improved.

In addition, when the server is judged to be in the offline state, the standby server is started, and after the communication connection with the standby server is established, the abnormal state of the server is reported to the standby server. The network fault of the server can be conveniently known by maintenance personnel, and the normal use of the server can be quickly recovered.

Drawings

FIG. 1 is a schematic diagram of an embodiment of a method for monitoring server survival status in the prior art;

FIG. 2 is a flowchart illustrating an embodiment of a method for monitoring server survival status according to the present application;

FIG. 3 is a flowchart illustrating an embodiment of step S14 of FIG. 2;

FIG. 4 is a flowchart illustrating a second embodiment of a method for monitoring server survival status according to the present application;

FIG. 5 is a flowchart illustrating a third embodiment of a method for monitoring server survival status according to the present application;

FIG. 6 is a broken line schematic diagram of one embodiment of the heartbeat packet frequency of the device of FIG. 5 over time;

FIG. 7 is a flowchart illustrating a fourth embodiment of a method for monitoring server survival status according to the present application;

FIG. 8 is a flowchart illustrating a fifth embodiment of a method for monitoring server survival status according to the present application;

FIG. 9 is a block diagram illustrating an embodiment of a system for monitoring server survivability according to the present application;

FIG. 10 is a schematic structural diagram of an embodiment of the heartbeat monitoring module of FIG. 9;

FIG. 11 is a schematic diagram of a second embodiment of a system for monitoring server survival status according to the present application;

FIG. 12 is a schematic diagram of a third embodiment of a system for monitoring server survival status according to the present application;

FIG. 13 is a schematic block diagram illustrating a fourth embodiment of a system for monitoring server survival status according to the present application;

FIG. 14 is a schematic block diagram illustrating a fifth embodiment of a system for monitoring server survivability according to the present application;

FIG. 15 is a schematic diagram illustrating a network architecture of an embodiment of a system for monitoring server survival status according to the present application;

FIG. 16 is a block diagram of an embodiment of a server of the present application;

FIG. 17 is a schematic diagram of the structure of an embodiment of the apparatus of the present application;

FIG. 18 is a schematic diagram of a network architecture of another embodiment of a system for monitoring server survival status according to the present application;

fig. 19 is a schematic network structure diagram of another embodiment of the system for monitoring server survival status according to the present application.

Detailed Description

In the following, in order to make the present application easier to understand, some common descriptions related to the embodiments of the present application are explained, and it should be noted that these explanations should not be construed as limiting the scope of protection claimed in the present application.

A, server

The server of the present application may be an entity device or a virtual server, and the server may be a process server or a remote server, which is not limited herein.

In the embodiment of the present application, if the server is an entity device, preferably, the communication standard that can be used for communication between the server and the device includes, but is not limited to, various near field communication standards, such as: bluetooth, near Field Communication (NFC), zigBee, infrared Data Association (IrDA), wireless Fidelity (WiFi), and the like.

Various wired or wireless communication modes can be adopted between the server and the equipment, and the wired communication modes include but are not limited to: ethernet and MODEM communication. Wireless communication means include, but are not limited to: 2G, 3G, 4G, 5G.

Any communication method may be adopted as long as communication between the server and the terminal can be achieved.

2. Device

The device comprises various types of internet-of-things entity devices, such as household appliance devices, intelligent household devices, security monitoring devices, data acquisition instrument devices, computer devices, intelligent terminals and the like, which are not listed herein.

3. Heartbeat packet frequency

As used herein, the term "heartbeat packet frequency" refers to the frequency at which a server (including a standby server) sends heartbeat packets to a device.

4. Comparison of transmission power consumption and reception power consumption of communication chip

Practice proves that the receiving power consumption of the communication chip is generally smaller than the sending power consumption, and for some chips, such as WIFI chips, the receiving power consumption is far smaller than the sending power consumption. In particular, please refer to the examples shown in the following table:

chip type	WIFI	WIFI	WIFI	2.4G	2.4G
						Chip type	CYW43438	Hi11315	CC3200	A7190	A7131
Receive power consumption	40mA	45mA	59mA	28mA	27mA
						Transmission power consumption (10 dBm)					25mA
Transmission power consumption (15 dBm)	260mA		229mA
						Transmission power consumption (17 dBm)				120mA
Transmission power consumption (18 dBm)	290mA	270mA
						Transmission power consumption (20 dBm)	320mA			183mA
Transmission power consumption (22 dBm)		352mA

Watch 1

Based on the above table one, we can analyze that:

1. except for the 2.4G chip with the model a7131, most of the near field communication chips have much larger transmission power consumption than reception power consumption, for example, the WIFI chip with the model cyw43438@15dbm has transmission power consumption 6.5 times of the reception power consumption.

2. Different types of communication chips, such as a WIFI chip and a 2.4G chip, have completely different transmission power consumption and reception power consumption, and have a large power consumption difference. For example, the model is cyw43438@15dbm of a WIFI chip and the model is a7190@17dbmd of a 2.4G chip, and the sending power consumption and the receiving power consumption of the WIFI chip are 2 times of the sending power consumption and the receiving power consumption of the WIFI chip.

3. The corresponding transmission power consumption of the communication chips of the same type and model under different power conditions is different, for example, when a WIFI chip with the model of CYW43438 works at 15dBm and 20dBm respectively, the corresponding transmission power consumption is different, the former is 260mA, and the latter is 320mA.

The first embodiment is as follows:

referring to fig. 2, fig. 2 is a flowchart illustrating an embodiment of a method for monitoring server survival status according to the present application. As shown in fig. 2, the method comprises the steps of:

s11: the server 10 establishes a communication connection with the device 20;

in step S11, there are various ways in which the server 10 establishes a communication connection with the device 20. Two common ways of establishing a communication connection are described below.

1. The server 10 and the device 20 establish a communication connection by sending a handshake packet. Specifically, the process of establishing the communication connection comprises the following steps:

(1) The server 10 sends a handshake packet to the device 20;

wherein the handshake packet conforms to a predetermined communication protocol format.

(2) The device 20 continues to receive the handshake packet, and if the device 20 receives the handshake packet, it indicates that the server 10 and the device 20 successfully establish a communication connection.

Where if device 20 receives a series of data packets, a data check is performed on the data packets to determine if the data packets are the handshake packets. After the data is verified, the device 20 returns an acknowledgement (e.g., the character "ACK") to the server 10. The server 10 receives the confirmation response, which indicates that the server 10 and the device 20 successfully establish the communication connection.

2. Server 10 and device 20 establish a communication connection through a socket. Note that at this time, a client socket is created at the server 10 and a server socket is created at the device 20.

The connection process between sockets can be divided into three steps: server monitoring, client request and connection confirmation.

(1) Monitoring by a server: the server side socket does not locate a specific client side socket, but is in a state of waiting for connection, and monitors the network state in real time.

(2) The client requests: means that a connection request is made by a client socket and the target to be connected is a server socket. For this purpose, the client socket must first describe the server socket to which it is to connect, indicate the address and port number of the server socket, and then make a connection request to the server socket.

(3) Connection confirmation: when a server side socket listens or receives a connection request of a client side socket, the server side socket responds to the request of the client side socket, a new thread is established, description of the server side socket is sent to a client side, and once the client side confirms the description, connection is established. And the server side socket is continuously in a monitoring state and continuously receives the connection requests of other client side sockets.

S12: the server 10 sets the heartbeat packet frequency of the device 20;

in step S12, the heartbeat packet frequency of the apparatus 20 may be set based on empirical values. For example, the server 10 is configured to send a heartbeat packet to the device 20 every 24S or 30S.

Optionally, a configuration file is provided in the server 10 to set the heartbeat packet frequency of the device 20. The heartbeat packet frequency of the device 20 may also be set directly in the application of the server 10. The server 10 may also be provided with a mobile terminal or a hand-held PDA to set the heartbeat packet frequency of the device 20.

S13: the server 10 transmits the heartbeat packet to the device 20 at a predetermined frequency.

In step S13, the server 10 transmits the heartbeat packet to the device 20 at intervals that match the heartbeat packet frequency set in step S12.

S14: the device 20 monitors heartbeat packets sent by the server 10;

step S14 is specifically described below. Referring to fig. 3, fig. 3 is a flowchart illustrating an embodiment of step S14 of fig. 2. Step S14 is performed by the apparatus 20 and comprises the steps of:

s141: receiving a heartbeat packet;

in step S141, the read function of the socket communication protocol may be called to receive the heartbeat packet.

S142: judging whether the heartbeat packet is successfully received at the time;

wherein, by comparing the data packet length of the heartbeat packet received in step S141 and whether the value of each byte in the heartbeat packet conforms to the expected value, it is determined whether the heartbeat packet is successfully received at the time.

For example, the length of the data packet of the heartbeat packet received in step S141 is 15 bytes, if the 15 bytes conform to the expected length of the heartbeat packet, then it is determined whether the data content of the heartbeat packet is correct, the content of each byte of the 15 bytes is compared with the content of each byte of the expected heartbeat packet one by one, and if the content of each byte is the same as the content of the expected byte, it is determined that the heartbeat packet is successfully received; otherwise, the heartbeat packet is judged to be unsuccessfully received.

In step S142, if the reception in step S141 is successful, step S144 is performed, and then step S12 is performed; otherwise, the next step S143 is executed.

S143: if the current receiving fails, judging whether the current receiving state meets a preset receiving stopping condition;

in step S143, if the current reception state does not satisfy the preset reception stop condition, returning to step S141 to continue receiving the heartbeat packet; otherwise, step S144 is executed.

Optionally, a timer is set in step S141; in step S143, it is determined whether the current reception status satisfies the predetermined reception stop condition: judging whether the elapsed time (or remaining time) of the current timer exceeds (is less than) a predetermined threshold value, and if so, deciding to stop reception; otherwise, the reception can be continued.

Optionally, the step of judging whether the current receiving state meets the preset receiving stop condition is: judging whether the total receiving times exceed a preset time, for example, setting the preset time to be 50 times; if the predetermined number of times is exceeded, determining to stop receiving; otherwise, the reception can be continued.

S144: the reception of the heartbeat packet is stopped.

It is to be understood that, in the implementation of the software program, steps S141 to S143 may be executed in a loop, and if the preset stop receiving condition is satisfied in step S143, the loop is interrupted and step S144 is executed.

S15: if the heartbeat packet is received within a predetermined time, the device 20 determines that the server 10 is in an alive state.

In step S15, it is noted that the predetermined time is longer than the time of the timer described in step S143, because a certain (perhaps very small) time is required to perform step S14. For example, if the device 20 does not receive the heartbeat packet sent by the server 10 within 72s, it indicates that the device 20 and the server 10 are not in the connected state, and the server 10 may be in the dropped state.

In the present embodiment, if the device 20 determines in step S15 that the server 10 is in the alive state, the device 20 loops through steps S14 to S15 to continuously determine whether the server 10 is in the alive state.

In this embodiment, the server 10 is adopted to send the heartbeat packet to the device 20, and whether the device 20 receives the heartbeat packet is monitored, so as to determine the survival status of the server 10. Compared with the prior art that the device 20 sends the heartbeat packet to the server 10, whether the server 10 is alive or not is judged by monitoring whether the device 20 receives a response reply of the server 10 or not; the device 20 in this embodiment may not need to transmit data, but only need to receive data, and thus does not consume transmit power consumption, but only needs to consume receive power consumption. Moreover, since the receiving power consumption of the device 20 is generally smaller than the sending power consumption, the monitoring method of the embodiment is beneficial to saving the overall power consumption of the device 20, so that the used electric energy of the device 20 is saved, and the current requirements of energy conservation and emission reduction are met. Particularly for passive devices, it may be advantageous to increase the battery life of device 20, thereby extending the life of device 20.

In addition, with the monitoring method of this embodiment, compared with the monitoring method in the prior art, for the device 20, data transmission is not required in each monitoring step, which is beneficial to saving the CPU and memory overhead of the device 20, so that the efficiency of the device 20 executing other main operations can be improved.

The second embodiment:

referring to fig. 4, fig. 4 is a flowchart illustrating a method for monitoring server survival status according to a second embodiment of the present application. The plurality of devices connected with the server can be of different types, for example, the devices can comprise cameras, televisions, underground water meter detectors and the like, the functions of the devices are different, the working modes of working scenes are different, and the requirements of timely reaction of the devices are different, so that different heartbeat packet frequencies can be set by different devices. The difference between this embodiment and the first embodiment is that the heartbeat packet frequency of the device is set by acquiring the static device parameters of the device.

As shown in fig. 4, the method includes the steps of:

s21: the server 10 establishes a communication connection with the device 20;

step S21 is the same as step S11 of the first embodiment.

S22: the server 10 obtains the static device parameters of the device 20, and calculates the heartbeat packet frequency of the device 20 according to the static device parameters;

in step S22, the static device parameters include: type of device, model, type and model of communication chip, importance, lifetime, total amount of battery, power, etc.

The step S22 may be implemented as follows:

(1) The server 10 obtains all static device parameters from the device 20, for example, when the server 10 establishes a communication connection with the device 20 for the first time, a specific communication command is sent to the device 20; after receiving the specific command, the device 20 sends its own static device parameters to the server 10.

(2) The server 10 obtains the device type and model of the device 20, and then queries a database of the server 10 for other static device parameters of the device 20, such as the type and model of the communication chip, the importance of the device, the lifetime, the total amount of battery, and the power, according to the type and model of the device 20.

It should be noted that the server 10 may not need to communicate with the device 20 directly or directly to obtain the static device parameters of the device 20. For example, the device type and model of the device 20 are manually configured in the server 10 through application software, or the device type and model of the device 20 are obtained by reading a configuration file, and then other static device parameters of the device 20 are queried in a database according to the device type and model; even further, the server 10 may obtain the static device parameters of the device 20 by receiving communication data from other mobile terminals.

Preferably, the heartbeat packet frequency of device 20 is calculated by empirical formula. The empirical formula takes into account the weight of each static plant parameter.

For ease of understanding, the empirical formula may be expressed as follows:

wherein, f ₀ Representing the heartbeat packet frequency, Δ m, of the device 20 _i A weight representing one of the static device parameters of the device 20, having a value greater than 0 and less than 1, and

η _i representing the corresponding heartbeat packet frequency when the weight of one static equipment parameter is 100%, and setting according to an empirical value; n represents the sum of the number of all static device parameters involved by the device 20.

According to the power consumption table (table one) of the communication chip, it can be found that the receiving power consumption of the communication chips of different types or models is different, so that different heartbeat packet frequencies are necessary to be set for different communication chips, for example, a heartbeat packet with a low frequency is set for a communication chip with still higher receiving power consumption, which is beneficial to reducing the overall power consumption in the working process of the device.

The effect of other static device parameters on setting the heartbeat packet frequency of the device 20 is explained in detail below.

(1) The importance of the device. For example, some of the less common devices may reduce their heartbeat packet frequency.

(2) The lifetime of the device. In order to prolong the service life of the equipment, the heartbeat packet frequency of the equipment with shorter service life needs to be reduced.

(3) Total battery of the device. In order to prolong the service life of the device, the heartbeat packet frequency of the device with less total battery is necessary to be reduced.

(4) The power of the device. In order to reduce the power consumption of the device, it is necessary to reduce the heartbeat packet frequency of the device with larger power consumption.

S23-S25: the same as steps S14-S15 of the first embodiment, respectively.

In this embodiment, the heartbeat packet frequency of the device is calculated according to the static device parameter of the device, and the static device parameter is closely associated with the power consumption or the service life of the device, so that different heartbeat packet frequencies are set for different devices 20, for example, a low-frequency heartbeat packet is sent to a device with a shorter battery life or a communication chip with a larger power consumption, so that the overall power consumption of the heartbeat packet monitored by such a device can be saved, and the service life of the device can be prolonged.

Example three:

referring to fig. 5, fig. 5 is a flowchart illustrating a method for monitoring server survival status according to a third embodiment of the present application. The difference between this embodiment and the second embodiment is that, further, after the server sends the heartbeat packet with fixed frequency to the device for a period of time, the dynamic device parameter of the device is obtained in real time, and the heartbeat packet frequency of the device is adjusted according to the dynamic device parameter.

As shown in fig. 5, the method includes the steps of:

s31: the same step as step S21 of the second embodiment;

s32: the server 10 obtains the static device parameters of the device 20, and calculates the first heartbeat packet frequency of the device 20 according to the static device parameters;

in step S32, the same as step S22 of the second embodiment, the first heartbeat packet frequency is the heartbeat packet frequency in step S22, and this step is referred to as the first heartbeat packet frequency.

S33: server 10 sends heartbeat packets to device 20 at a first frequency;

step S33 is the same as step S23 of the embodiment.

S34: after the device 20 operates for a period of time, the server 10 obtains the dynamic device parameters of the device 20 in real time, and calculates a second heartbeat packet frequency of the device 20 according to the static device parameters and the dynamic device parameters;

in step S34, the dynamic device parameters include: the running time of the equipment, the current total amount of the battery, the current power consumption, the current time, whether a server needs to be connected or not and the like.

Alternatively, the server 10 automatically obtains dynamic device parameters for the device 20 at intervals. For example, setting the dynamic device parameters of the device 20 to be acquired every 2 hours in the application program of the server 10; or by setting the time interval at which the device 20 acquires the dynamic device parameters via a profile or hand-drawn graph.

Optionally, a manual button is set on the server 10, and when the manual button is clicked, the server 10 may obtain the dynamic device parameters of the device 20 in real time, so that the maintenance personnel can adjust the heartbeat packet frequency of the device 20 at any time.

In step S35, the calculation formula for calculating the second heartbeat packet frequency according to the dynamic device parameter may refer to step S22 of the second embodiment, that is, the dynamic device parameter obtained in step S34 is added to the heartbeat packet frequency calculation formula.

Optionally, the formula for calculating the second heartbeat packet frequency is as follows:

wherein f is ₀ Representing the first heartbeat packet frequency, f _t Representing the second heartbeat packet frequency, m representing the total number of dynamic device parameters, Δ τ _j Representing the influence factor, value, of the jth dynamic device parameter on the frequency of heartbeat packetsIs greater than 0.

The following describes each dynamic device parameter and its corresponding influence factor on the heartbeat packet frequency.

(1) The current power consumption. Optionally, if the current power consumption of the device 20 is greater than the rated power consumption of the device 20, the impact factor = rated power consumption/current power consumption.

(2) The current battery level. Alternatively, if the current battery level of device 20 is less than the predetermined threshold, then the impact factor = current battery level/battery level threshold.

(3) The length of the run. Optionally, if the device 20 operation duration exceeds the predetermined threshold, the impact factor = device operation duration threshold/current device operation duration.

(4) The current time. Optionally, the influencing factor is preset according to the operating characteristics of the device 20.

(5) If the server is connected, and the corresponding influence factor τ is 1 or 0, that is, the device 20 does not need to connect to the server 10, setting τ to 0, that is, the server 10 does not send the heartbeat packet to the device 20; otherwise, τ is set to 1, that is, the server 10 sends the heartbeat packet to the device 20. The scene is applied to: for example, the device 20 is an electric energy collecting terminal, and such a device only needs to communicate with the server 10 in a specific time period (for example, 23.

S35: the server 10 sends heartbeat packets to the device 20 at the second heartbeat packet frequency;

the method for sending the heartbeat packet in step S35 is the same as the method for sending the heartbeat packet in step S33 in the embodiment, except that the frequency of sending the heartbeat packet is different.

S36: the same as step S24 of the second embodiment. S37: the same as step S25 of the second embodiment.

After step S37 is executed, it is understood that steps S34 to S37 are cyclically executed.

Referring to fig. 7, fig. 7 is a broken line diagram of an embodiment of the variation of the heartbeat packet frequency of the device 20 (an electric energy harvester) with time. As shown in fig. 7, the heartbeat packet frequency of device 20 is in the range of 20: time period 00-22, corresponding to a value of 4 times/hour; at time period 22; in a time period of 24.

In this embodiment, the heartbeat packet frequency of the device is adjusted at regular or irregular intervals by obtaining the running time of the device and whether dynamic device parameters such as communication with a server are required, and compared with the method of the second embodiment, the heartbeat packet frequency of the device can be flexibly adjusted in this embodiment, so that the overall power consumption of the heartbeat packet is flexibly adjusted and monitored, the power consumption of the device in the working process is further reduced, and the service life of the device is prolonged.

Example four:

referring to fig. 7, fig. 7 is a flowchart illustrating a method for monitoring server survival status according to a fourth embodiment of the present application. As shown in fig. 7, the present embodiment is different from the first embodiment in that: when the server is preliminarily determined to be in the non-survival state, in order to eliminate some abnormal conditions, such as disturbance of a communication network, the heartbeat packet is sent to the server again through the device, and whether the server is in the survival state is further determined. The method comprises the following steps:

S41-S45: the same steps as steps S11-S15 of the first embodiment.

S46: after not receiving the heartbeat packet within the predetermined time, device 20 initiates a request to establish a connection to server 10.

In step S46, optionally, a client-side socket is created at the device 20 and a server-side socket is created at the server 10 at this time. Specifically, the method for establishing a communication connection through a socket is described in detail in step S11 of the first embodiment, and is not described herein again.

S47: if the establishment of the communication connection with the server 10 is successful, the device 20 determines that the server 10 is in the alive state.

In step S47, if the device 20 successfully receives the connection request response reply of the server 10, it is determined that the establishment of the communication connection with the server 10 is successful.

After determining that the server 10 is in the alive state, step S47 is terminated, and the server 10 returns to re-execute steps S44 to S47.

In this embodiment, compared to the first embodiment, the determination of whether the server 10 is in the alive state through the steps S46 and S47 is further performed, which is beneficial to improve the accuracy of determining whether the server 10 is in the alive state by the apparatus 20. It is understood that the methods of step S46 and step S47 of the present embodiment may also be performed after the last step of embodiment two or embodiment three.

Example five:

referring to fig. 8, fig. 8 is a flowchart illustrating an embodiment of a method for monitoring server survival status according to the present invention. The present embodiment is different from the fourth embodiment in that: upon further determining that the server is in the dropped state, the device 20 further establishes a communication connection with the standby server 30, and reports to the standby server 30 that the server 10 is in the dropped state. As shown in fig. 8, the method includes the steps of:

S51-S57: the same steps as steps S41-S47 of the first embodiment.

S58: after failing to establish a communication connection with server 10, device 20 initiates a connection establishment request to standby server 30;

in step S58, the method for device 20 to initiate a connection establishment request to standby server 30 is the same as the method for device 20 to initiate a connection establishment request to server 10, and is not described herein again.

S59: if the connection establishment with the standby server 30 is successful, the device 20 reports to the standby server 30 that the server 10 is in a dropped state.

In step S59, device 20 may report to standby server 30 an abnormal communication data record of device 20 in addition to reporting to standby server 30 that server 10 is in a dropped state. Preferably, the abnormal communication data record records abnormal data information of the heartbeat packet transmitted and received between the server 10 and the device 20 in the form of log files. Device 20 uploads the log file to standby server 30. The advantage of using a log file is that it facilitates the storage of the exception data information on the standby server 30.

Preferably, when receiving the state that the server 10 is in the off-line state, the standby server 30 sends out an alarm prompt message in the form of a sound signal or an optical signal, for example, a speaker is used to send out a prompt sound to remind the maintenance personnel to perform the inspection.

It should be noted that the number of standby servers 30 is not limited, and if the device 20 cannot establish a connection with the first standby server, the device 20 may establish a connection with the second standby server. Alternatively, the hardware and software configuration of the standby server 30 is the same as that of the server 10.

In the present embodiment, if it is determined that the server 10 is in the dropped state, communication between the server 10 and the device 20 is not possible, and the device 20 maintains normal operation of the device 20 by establishing a communication connection with the standby server 30.

Further, the device 20 of the present embodiment may also report the offline state of the server 10 to the standby server 30, so that the maintenance personnel can know that the server 10 has a failure.

In addition, the present embodiment may send the log record to the standby server 30, so that the standby server 30 may analyze the reason for the offline fault of the server 10 according to the log record, thereby quickly removing the fault of the server 10 and restarting the server 10 to operate normally.

Example six:

please refer to fig. 9 and 10 together. Fig. 9 is a schematic structural diagram of an embodiment of a system for monitoring server survival status according to the present application. As shown in fig. 9, the server 10 includes a communication connection establishing module 11, a heartbeat packet frequency acquiring module 12, and a heartbeat packet transmitting module 13. The device 20 includes a heartbeat packet monitoring module 21 and a server survival status determination module 22.

Wherein, the communication connection establishing module 11 is configured to establish a communication connection with the device 20. A heartbeat packet frequency obtaining module 12, configured to obtain a heartbeat packet frequency of the device 20. A heartbeat packet sending module 13, configured to send a heartbeat packet to the device 20 based on the heartbeat packet frequency.

The following describes the operation of each module of the server 10.

The method for establishing the communication connection between the communication connection establishing module 11 and the device 20 is described in detail in the first embodiment, and is not described herein again.

The heartbeat packet frequency obtaining module 12 is configured to set the heartbeat packet frequency of the device 20 according to the empirical value. For example, the server 10 is configured to send heartbeat packets to the device 20 every 24S or 30S. Optionally, a configuration file is provided in the server 10 to set the heartbeat packet frequency of the device 20. The heartbeat packet frequency of the device 20 may also be set directly in the application program of the server 10. The server 10 may also be provided with a mobile terminal or a hand-held PDA to set the heartbeat packet frequency of the device 20.

The heartbeat packet sending module 13 is configured to send a heartbeat packet to the device 20 at a time interval, where the time interval is in accordance with the heartbeat packet frequency set by the heartbeat packet frequency obtaining module 12.

The operation of the modules of the apparatus 20 is described in detail below.

The heartbeat packet monitoring module 21 is configured to monitor a heartbeat packet sent by the server 10. Server alive state the first decision module 22 is configured to decide that the server 10 is alive if the heartbeat packet is received within a predetermined time.

Referring to fig. 10, the heartbeat packet monitoring module 21 includes a heartbeat packet receiving unit 211, a heartbeat packet receiving success determining unit 212, a heartbeat packet receiving stop determining unit 213, and a heartbeat packet receiving stop unit 214. The following describes the operation method of the heartbeat packet monitoring module 21.

Optionally, the heartbeat packet receiving unit 211 is configured to call a read function of the socket communication protocol to receive the heartbeat packet.

Optionally, the heartbeat packet receiving success determining unit 212 is configured to determine whether the heartbeat packet is successfully received at the present time by comparing the data packet length of the heartbeat packet received by the heartbeat packet receiving unit 211 and whether the value of each byte in the heartbeat packet meets an expected value.

For example, the length of the data packet of the heartbeat packet received by the heartbeat packet receiving unit 211 is 15 bytes, if the 15 bytes conform to the expected length of the heartbeat packet, then it is determined whether the data content of the heartbeat packet is correct, the content of each byte of the 15 bytes is compared with the content of each byte of the expected heartbeat packet one by one, if the content of each byte is the same as the content of the expected byte, it is determined that the heartbeat packet is successfully received; otherwise, the heartbeat packet is judged to be unsuccessfully received.

A heartbeat packet receiving success judging unit 212, configured to invoke the heartbeat packet receiving stopping unit 214 if the heartbeat packet receiving unit 211 successfully receives the heartbeat packet, and then the server 20 recalls the heartbeat packet monitoring module 21 and the server survival state first judging module 22; otherwise, the judging unit 213 is invoked to determine whether the heartbeat packet reception is stopped.

The heartbeat packet reception stop determining unit 213 is configured to determine whether the current reception state meets a preset reception stop condition if the heartbeat packet reception success determining unit 212 fails to receive the heartbeat packet at the next time.

The heartbeat packet receiving stop determining unit 213 is further configured to invoke the heartbeat packet receiving unit 211 to continue receiving the heartbeat packet if the current receiving state does not meet the preset receiving stop condition; otherwise, the heartbeat packet reception stopping unit 214 is invoked to stop receiving heartbeat packets, and the server 10 determines that the heartbeat packet of the device 20 is not accepted.

Alternatively, a timer is set in the heartbeat packet receiving unit 211; the heartbeat packet reception stop determining unit 213 determines whether the current reception state satisfies the predetermined reception stop condition: judging whether the elapsed time (or remaining time) of the timer at this time exceeds (is less than) a predetermined threshold, and if so, deciding to stop reception; otherwise, the reception can be continued.

Alternatively, the heartbeat packet reception stop determining unit 213 determines whether the current reception state satisfies the preset reception stop condition as follows: determining whether the total number of times of invoking the heartbeat packet receiving unit 211 to receive the heartbeat packets exceeds a predetermined number of times, for example, setting the predetermined number of times to be 50 times; if the predetermined number of times is exceeded, determining to stop receiving; otherwise, the reception can be continued.

The heartbeat packet reception stopping unit 214 is configured to stop receiving heartbeat packets.

And the server survival state judgment module 22 is used for judging that the server is in a survival state if the heartbeat packet is received.

In this embodiment, the server 10 sends the heartbeat packet to the device 20 by invoking the heartbeat packet sending module 13, and the device 20 monitors the heartbeat packet by invoking the heartbeat packet monitoring module 21 to determine the survival status of the server 10. Compared with the prior art that the device 20 sends the heartbeat packet to the server 10 and whether the response reply of the server 10 is received by the monitoring device 20 or not, the device 20 in this embodiment does not need to send data but only needs to receive data, so that sending power consumption is not consumed and only receiving power consumption is consumed. Moreover, since the receiving power consumption of the device 20 is generally smaller than the sending power consumption, the method for determining whether the server 10 is alive by using the server 10 and the device 20 according to the embodiment is beneficial to saving the overall power consumption of the device 20, so that the power consumption of the device 20 is saved, and the current situation of energy conservation and emission reduction is met.

If device 20 is a passive device, it may be advantageous to increase the useful life of the battery of device 20, thereby extending the useful life of device 20.

In addition, in the monitoring process of the device 20 of this embodiment, it is not necessary to send a heartbeat packet data packet to the server 10, which is beneficial to saving the overhead of the CPU and the memory of the device 20, so as to improve the working efficiency of the device 20.

Example seven:

referring to fig. 11, fig. 11 is a schematic structural diagram of a system for monitoring server survival status according to a second embodiment of the present application. The plurality of devices connected with the server can be of different types, for example, the devices can comprise cameras, televisions, underground water meter detectors and the like, the functions of the devices are different, the working modes of working scenes are different, and the requirements of timely reaction of the devices are different, so that different heartbeat packet frequencies can be set by different devices. The difference between this embodiment and the sixth embodiment is that the heartbeat packet frequency of the device is set by the heartbeat packet frequency calculation module 12 obtaining the static device parameters of the device.

As shown in fig. 11, the server 10 includes a communication connection establishment module 11, a heartbeat packet frequency calculation module 12, and a heartbeat packet transmission module 13. The device 20 includes a heartbeat packet monitoring module 21 and a server survival status determination module 22. The communication connection establishing module 11, the heartbeat packet sending module 13, the heartbeat packet monitoring module 21, and the server survival status determining module 22 are the same as those in the sixth embodiment, and are not described herein again.

The heartbeat packet frequency calculation module 12 is described in detail below. The heartbeat packet frequency calculating module 12 is configured to obtain a static device parameter of the device 20, and calculate a heartbeat packet frequency of the device 20 according to the static device parameter. Wherein the static device parameters include: type of device, model, type and model of communication chip, importance, lifetime, total amount of battery, power, etc.

The present embodiment is a system embodiment corresponding to the second embodiment. Please refer to the description of the second embodiment for the implementation process and the beneficial effects of this embodiment, which are not described herein again.

Example eight:

referring to fig. 12, fig. 12 is a schematic structural diagram of a system for monitoring server survival status according to a third embodiment of the present application. The difference between this embodiment and the seventh embodiment is that after the first heartbeat packet sending module 13 sends the heartbeat packets with fixed frequency to the device for a certain period of time, further, the second heartbeat packet frequency calculating module 14 and the second heartbeat packet sending module 15 obtain the dynamic device parameters of the device in real time, and adjust the heartbeat packet frequency of the device according to the dynamic device parameters.

As shown in fig. 12, the server 10 includes a communication connection establishing module 11, a first heartbeat packet frequency calculating module 12, a first heartbeat packet transmitting module 13, a second heartbeat packet frequency calculating module 14, and a second heartbeat packet transmitting module 15. The device 20 includes a heartbeat packet monitoring module 21 and a server survival status determination module 22.

The communication connection establishing module 11, the first heartbeat packet frequency calculating module 12, the first heartbeat packet sending module 13, the heartbeat packet monitoring module 21, and the server survival state determining module 22 are the same as those in the seventh embodiment, and are not described herein again. The second heartbeat packet frequency calculation module 14 is described in detail below.

The second heartbeat packet frequency calculating module 14 is configured to obtain the dynamic device parameters of the device 20 in real time after the device 20 runs for a period of time, and calculate the second heartbeat packet frequency of the device 20 according to the static device parameters and the dynamic device parameters. The second heartbeat packet sending module 15 is configured to send the heartbeat packets to the device 20 at the second heartbeat packet frequency.

Preferably, the dynamic device parameters include: the running time of the equipment, the current total amount of the battery, the current power consumption, the current time, whether a server needs to be connected or not and the like.

Optionally, the second heartbeat packet frequency calculation module 14 automatically obtains dynamic device parameters for the device 20 at intervals. For example, setting the dynamic device parameters of the device 20 to be obtained every 2 hours; or the time interval at which the device 20 acquires the dynamic device parameters may be set by way of a profile or hand-drawn graph. The server 10 is provided with a manual button, and when the manual button is clicked, the second heartbeat packet frequency calculation module 14 can immediately obtain the dynamic device parameters of the device 20, so that the maintenance personnel can adjust the heartbeat packet frequency of the device 20 at any time.

This embodiment is a system embodiment corresponding to the third embodiment. Please refer to the description of the third embodiment for the implementation process and the beneficial effects of this embodiment, which are not described herein again.

Example nine:

referring to fig. 13, fig. 13 is a schematic structural diagram of a system for monitoring server survival status according to a fourth embodiment of the present application. As shown in fig. 13, the present embodiment is different from the sixth embodiment in that: the device 20 further includes a connection establishing request module 23 with the server and a second determination module 24 for determining the server survival state, and when the server is preliminarily determined to be in the non-survival state, in order to eliminate some abnormal situations, such as disturbance of the communication network, the heartbeat packet is sent to the server again through the device, so as to further determine whether the server is in the survival state.

The connection establishing request module 23 is configured to initiate a connection establishing request to the server after the heartbeat packet is not received within the predetermined time. The server survival status second determination module 24 is configured to determine that the server is in a survival status if the establishment of the communication connection with the server is successful.

The server alive state second determination module 24 is configured to determine that the establishment of the communication connection with the server is successful if a connection request reply of the server is successfully received.

In this embodiment, compared with the sixth embodiment, the connection establishing request module 23 and the server survival state second determination module 24 are used to further determine whether the server 10 is in the survival state, which is beneficial to improving the accuracy of determining whether the server 10 is in the survival state by the device 20. It is to be understood that, after the first determination module 22 for server survival status in the seventh embodiment or the eighth embodiment, a connection request module 23 for establishing connection with a server and a second determination module 24 for server survival status may also be added.

Example ten:

referring to fig. 14, fig. 14 is a schematic structural diagram of a fifth embodiment of a system for monitoring server survival status according to the present application. The present embodiment differs from the ninth embodiment in that: the apparatus 20 further includes a request to establish a connection with a standby server module 25 and a server exception status reporting module 26.

The connection establishment request module 25 is configured to initiate a connection establishment request to a standby server (not shown) after a failure of establishing a connection with the server.

And a server abnormal condition reporting module 26, configured to report to the standby server that the server is in a dropped state if the connection establishment with the standby server is successful.

Server exception status reporting module 26 is used to report to the standby server the exception communication data records of device 20 in addition to reporting to the standby server that server 10 is in a dropped state. Preferably, the abnormal communication data record records abnormal data information of the heartbeat packet transmitted and received between the server 10 and the device 20 in the form of log files. The server exception status reporting module 26 uploads the log file to the standby server 30. The advantage of using a log file is that it facilitates the storage of exception data information on the standby server 30.

Preferably, when receiving the state that the server 10 is in the off-line state, the standby server sends out an alarm prompt message in the form of a sound signal or an optical signal, for example, a speaker is used to send out a prompt sound to remind a maintenance person to perform an inspection.

It should be noted here that the number of the standby servers is not limited, and if the connection establishing request module 25 with the standby server cannot establish a connection with the first standby server, the connection establishing request module 25 with the standby server is also used for establishing a connection with the second standby server. Optionally, the hardware and software configuration of the standby server is the same as that of the server 10.

In the present embodiment, if the server alive state second determination module 24 determines that the server 10 is in the dropped state and communication between the server 10 and the device 20 is not possible, the communication connection is established with the standby server 30 through the connection establishment request module 25 with the standby server so that the device 20 keeps operating normally.

Further, the device 20 of the present embodiment may also report the dropped state of the server 10 to the standby server 3 through the server abnormal condition reporting module 26, so as to facilitate a maintenance person to know that the server 10 has a failure.

In addition, the device 20 of the present embodiment sends the log record of the device 20 to the standby server through the server abnormal condition reporting module 26, so that the standby server 30 can analyze the reason for the offline fault of the server 10 according to the log record, thereby quickly eliminating the fault of the server 10 and restarting the server 10 to normally operate.

Example eleven:

referring to fig. 15 to 17, fig. 15 is a schematic network structure diagram of a system for monitoring server survival status according to an embodiment of the present application. As shown in fig. 15, the monitoring system includes a first device 20, a second device 40, a third device 50, a fourth device 60, and a server 10. The server 10 communicates with a first device 20, a second device 40, a third device 50 and a fourth device 60, respectively. Any one of the four devices is selected to determine whether the server 10 is in a live state.

Preferably, when the current determination device reaches a preset condition, such as the battery power of the current determination device is lower than a predetermined threshold, or when the working duration of the current determination device reaches a predetermined working duration, other devices may be activated to continuously determine whether the server 10 is in a survival state. Since the device parameters of the first device 20, the second device 40, the third device 50, and the fourth device 60 are different, when the other device is switched to continue the determination, the heartbeat packet frequency of the other device is recalculated according to the device parameter characteristics of the other device.

For example, with the first device 20, the heartbeat packet frequency is set to 5 times/minute; when the second device 40 is employed, the heartbeat packet frequency is set to 3 times/minute; when the third device 50 is employed, the heartbeat packet frequency is set to 2 times/minute; when the fourth device 60 is employed, the heartbeat packet frequency is set to 1 time per minute.

Referring to fig. 16, as shown in fig. 16, the server 10 includes a communication module and a processor 101. Wherein the communication module comprises a transmitter 102 and a receiver 103, the communication module being adapted to establish a communication connection with the device. And a processor 101, configured to obtain a heartbeat packet frequency of the device. A transmitter 102, further configured to send heartbeat packets to the device based on the heartbeat packet frequency.

The server 10 further comprises a memory 104, a display 105 and physical keys 106. The memory 104 may be used to store programs, and the stored programs may be used to control the various units and devices described above. In addition, the memory 104 may also store intermediate variable data generated during the operation of the processor 101, such as heartbeat packet frequency.

And a display screen 105 for displaying the heartbeat packet frequency data generated by the processor 101. Optionally, the display screen 105 may have a touch function, in which case the display screen 105 is a touch display screen and is configured to receive a screen touch operation of a user and provide input operation information of the user to the processor 101.

The physical keys 106 may be used for receiving user input operations, such as: selects an option or the like displayed on the screen, and transmits information of the user's input operation to the processor 101 for processing by the processor 101.

Referring to fig. 17, as shown in fig. 17, the apparatus 20 includes a processor 201, a transmitter 202 and a receiver 203.

A receiver 203, configured to receive the heartbeat packet sent by the server 10.

And a processor 201, configured to determine that the server 10 is in a survival state if the heartbeat packet is received.

A transmitter 202 for initiating a request to establish a connection to the server 10 if the heartbeat packet is not received.

The receiver 203 is further configured to receive a connection establishment request response sent by the server 10; the processor 201 is further configured to determine that the server 10 is in an alive state if the device 20 establishes a connection with the server 10 successfully.

Here, it is explained that the transmitter 102 and the receiver 103 of the server 10 are paired with the transmitter 202 and the receiver 203 of the device 20, respectively. If the transmitter 102 and the receiver 103 of the server 10 are bluetooth communication modules, the transmitter 202 and the receiver 203 of the device 20 are also bluetooth communication modules.

Example twelve:

referring to fig. 18, fig. 18 is a schematic network structure diagram of a system for monitoring server survival status according to another embodiment of the present application. As shown in fig. 18, the monitoring system includes a server 10, a first device 20, a standby server 30, and a second device 40. The first device 20 is connected to the server 10 and the standby server 30, respectively. The second device 40 is connected to the server 10 and the standby server 30, respectively.

When the monitoring system works, firstly, the server 10 and the first device 20 establish communication connection, the server 10 sends a heartbeat packet to the first device 20, and if the first device 20 receives the heartbeat packet within a preset time, the server 10 is judged to be in a survival state; otherwise, it is determined that the server 10 may be in a dropped state, at this time, the server 10 initiates a request for establishing communication to the device 20, and if the server 10 and the device 20 successfully establish a communication connection, it indicates that the server 10 is in a alive state; otherwise, it indicates that the server 20 is in a dropped state, the server 20 initiates a request for establishing a communication connection to the standby server 30, and if the communication connection with the standby server 30 is successfully established, reports that the server 10 is in a dropped state to the standby server 30, so as to prompt a maintenance person to check and repair the server 10.

Furthermore, if the first device 20 is restricted from being continuously used to determine whether the server 10 is alive due to reaching a preset condition after operating for a period of time, the second device 40 is enabled to communicate with the server 10 to determine whether the server 10 is alive. At this time, the second device 40 is regarded as a backup device of the first device 20.

Example thirteen:

referring to fig. 19, fig. 19 is a schematic network structure diagram of a system for monitoring server survival status according to another embodiment of the present application. As shown in fig. 19, the monitoring system includes a server 10, a device 20, a standby server 30, and a mobile terminal 80. Wherein the server 10, the device 20 and the standby server 30 function the same as in the previous embodiments.

The mobile terminal 80 is described in detail below. The mobile terminal 80 is used to communicate with the server 10 to view the operating conditions of the server 10 and to set the operating parameters of the server 10.

The mobile terminal 80 may be used to view a heartbeat packet frequency change line graph set by the server 10. Specifically, the mobile terminal 80 is provided with a graphical interface to display a line graph of the frequency of heartbeat packets sent by the server 10 over time.

The mobile terminal 80 may be used to set the heartbeat packet frequency of the device 20. Specifically, the mobile terminal 80 provides a text box for setting the heartbeat packet frequency of the device 20, the mobile terminal 80 sends the set heartbeat packet frequency data to the server 10, and the server 10 sends the heartbeat packet to the device 20 according to the heartbeat packet frequency.

In the embodiment, the mobile terminal 80 is used for checking the working condition of the server 10 and setting the working parameters of the server 10, so that the use of the server 10 by maintenance personnel is convenient to monitor.

In summary, the present application provides a method, an apparatus, and a system for detecting a server survival status, which can monitor the server survival status. The device of the application does not need to consume the sending power consumption in the monitoring process, only needs to consume the receiving power consumption, and compared with the prior art, the device needs to consume the sending power consumption and the receiving power consumption simultaneously in the monitoring process, the whole power consumption in the monitoring process of the device is favorably reduced, the energy consumption of the device is favorably saved, and the service life of the device is prolonged.

Claims

1. A method for monitoring server survival status, performed by a server, comprising:

setting heartbeat packet frequency of the equipment according to equipment parameter characteristics of the equipment connected with the server, wherein the heartbeat packet frequency comprises a first heartbeat packet frequency obtained based on static equipment parameters of the equipment and a second heartbeat packet frequency obtained based on dynamic equipment parameters of the equipment;

sending heartbeat packets to the device based on the heartbeat packet frequency;

and after the heartbeat packet is sent according to the first heartbeat packet frequency at intervals for a period of time, the heartbeat packet frequency of the equipment is adjusted to be the second heartbeat packet frequency at intervals.

2. The method of claim 1, wherein setting the heartbeat packet frequency of the device according to device parameter characteristics of the device comprises:

obtaining static device parameters of the device, wherein the static device parameters include: type, model, importance, lifetime, total amount of battery, power, and type and model of communication chip;

calculating the heartbeat packet frequency according to the static equipment parameters, and recording the heartbeat packet frequency as a first heartbeat packet frequency, wherein a calculation formula of the first heartbeat packet frequency is as follows:

wherein f is ₀ Represents the heartbeat packet frequency, deltam, of the device (20) _i A weight representing one of the static equipment parameters of the equipment (20), the value being greater than 0 and less than 1, and

η _i representing the corresponding heartbeat packet frequency when the weight of one static equipment parameter is 100%, and setting according to an empirical value; n represents the sum of the number of all static device parameters involved in the device (20).

3. The method of claim 2, wherein obtaining the static device parameters of the device comprises:

acquiring the equipment type and model of the equipment;

and inquiring other static equipment parameters of the equipment according to the type and the model of the equipment.

4. The method of claim 2 or 3, wherein the interval adjusting the heartbeat packet frequency of the device comprises:

acquiring dynamic device parameters of the device at intervals, wherein the dynamic device parameters comprise: the working time, the current total amount of the battery, the current power consumption, the current time and whether a server needs to be connected or not;

recalculating the heartbeat packet frequency of the device according to the dynamic device parameter, and recording the recalculated heartbeat packet frequency as a second heartbeat packet frequency, wherein a calculation formula of the second heartbeat packet frequency is as follows:

wherein f is ₀ Representing the first heartbeat packet frequency, f _t Representing the second heartbeat packet frequency, m representing the total number of dynamic device parameters, Δ τ _j And the influence factor of the jth dynamic device parameter on the heartbeat packet frequency is represented, and the value is greater than 0.

5. A method of monitoring server survival status, performed by a device in communication with a server, comprising:

monitoring data sent by the server, and judging whether the data is a heartbeat packet, wherein the frequency of the heartbeat packet is generated according to the equipment parameter characteristics of the equipment, the frequency of the heartbeat packet comprises a first heartbeat packet frequency obtained based on the static equipment parameters of the equipment and a second heartbeat packet frequency obtained based on the dynamic equipment parameters of the equipment, and after the server sends the heartbeat packet according to the first heartbeat packet frequency for a period of time, the frequency of the heartbeat packet of the equipment is adjusted to be the second heartbeat packet frequency at intervals;

and if the heartbeat packet is received within the preset time, judging that the server is in a survival state.

6. The method of claim 5, further comprising:

requesting to establish a communication connection with the server after the heartbeat packet is not received within the predetermined time;

and if the communication connection with the server is successfully established, judging that the server is in a survival state.

7. The method of claim 5 or 6, further comprising:

and sending the equipment parameters to the server, wherein the equipment parameters comprise static equipment parameters and dynamic equipment parameters.

8. A server, comprising:

the heartbeat packet frequency setting module is used for setting heartbeat packet frequency of the equipment according to equipment parameter characteristics of the equipment connected with the server, wherein the heartbeat packet frequency comprises a first heartbeat packet frequency obtained based on static equipment parameters of the equipment and a second heartbeat packet frequency obtained based on dynamic equipment parameters of the equipment;

and the heartbeat packet sending module is used for sending heartbeat packets to the equipment based on the heartbeat packet frequency, and after the heartbeat packets are sent at the first heartbeat packet frequency at intervals for a period of time, the heartbeat packet frequency of the equipment is adjusted at intervals as the second heartbeat packet frequency.

9. An apparatus, comprising:

the heartbeat packet monitoring module is used for monitoring data sent by a server and judging whether the data is the heartbeat packet, the frequency of the heartbeat packet is generated according to the equipment parameter characteristics of the equipment, the frequency of the heartbeat packet comprises a first heartbeat packet frequency obtained based on the static equipment parameters of the equipment and a second heartbeat packet frequency obtained based on the dynamic equipment parameters of the equipment, and the server adjusts the heartbeat packet frequency of the equipment to be the second heartbeat packet frequency at intervals after sending the heartbeat packet according to the first heartbeat packet frequency for a period of time;

the server survival state judging module is used for judging whether the server is in a survival state or not according to whether the heartbeat packet is received within preset time or not;

and the equipment parameter sending module is used for sending the equipment parameters to the server, wherein the equipment parameters comprise static equipment parameters and dynamic equipment parameters.

10. A system for monitoring server survival status, comprising: the server of claim 8 and the device of claim 9, the system further comprising a backup server;

the equipment is also used for initiating a connection establishment request to the standby server after the connection establishment with the server fails; and if the connection with the standby server is successfully established, reporting the server disconnection condition to the standby server.