CN113032223B - Server state detection method and device - Google Patents
Server state detection method and device Download PDFInfo
- Publication number
- CN113032223B CN113032223B CN202110423303.4A CN202110423303A CN113032223B CN 113032223 B CN113032223 B CN 113032223B CN 202110423303 A CN202110423303 A CN 202110423303A CN 113032223 B CN113032223 B CN 113032223B
- Authority
- CN
- China
- Prior art keywords
- server
- detected
- state
- determining
- 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.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate
Abstract
The application provides a server state detection method and a server state detection device, wherein the server state detection method is applied to a central server and comprises the following steps: sending a state test request to a server to be detected; determining the communication state of the server to be detected according to state test information returned by the server to be detected in response to the state test request; sending a heartbeat request to the server to be detected, and determining the heartbeat state of the server to be detected according to heartbeat information fed back by the server to be detected; the operation state of the server to be detected is detected according to the communication state and the heartbeat state, and the operation state of the server to be detected can be comprehensively judged from different dimensions by the method provided by the application, so that the normal operation of subsequent services is ensured.
Description
Technical Field
The application relates to the technical field of internet, in particular to a server state detection method. The application also relates to a server state detection device, a computing device and a computer readable storage medium.
Background
With the development of internet technology, various live broadcast services applied to live broadcast are more and more, and the requirements on the picture stability during watching of live broadcast, namely the stability of a live broadcast server, are higher and higher.
In the existing live broadcast system, a main broadcast generally pushes a live stream to a live edge computing node, the edge computing node forwards the live stream to each CDN, and a user pulls the live stream through each CDN to view the live stream, so that an operating state of the edge computing node needs to be detected to select an available edge computing node for a stream pushing service, and if the detection is not accurate, the problem that the available edge computing node becomes few or the stream pushing service cannot be used normally is caused, so that viewing experience of the main broadcast stream and the user is directly affected.
Disclosure of Invention
In view of this, the present application provides a method for detecting a server status. The application also relates to a server state detection device, a computing device and a computer readable storage medium, which are used for solving the problem that the normal operation of subsequent services is influenced due to inaccurate state detection of edge computing nodes caused by no interaction between heartbeat service and plug flow service in the prior art.
According to a first aspect of the embodiments of the present application, there is provided a server state detection method, applied to a central server, including:
sending a state test request to a server to be detected;
determining the communication state of the server to be detected according to state test information returned by the server to be detected in response to the state test request;
sending a heartbeat request to the server to be detected, and determining the heartbeat state of the server to be detected according to heartbeat information fed back by the server to be detected;
and detecting the running state of the server to be detected according to the communication state and the heartbeat state.
According to a second aspect of the embodiments of the present application, there is provided a server status detection apparatus, applied to a central server, including:
the sending module is configured to send a state testing request to the server to be detected;
the first determining module is configured to determine the communication state of the server to be detected according to state testing information returned by the server to be detected in response to the state testing request;
the second determining module is configured to send a heartbeat request to the server to be detected, and determine a heartbeat state of the server to be detected according to heartbeat information fed back by the server to be detected;
and the detection module is configured to detect the running state of the server to be detected according to the communication state and the heartbeat state.
According to a third aspect of embodiments of the present application, there is provided a computing device comprising a memory, a processor, and computer instructions stored on the memory and executable on the processor, the processor implementing the steps of the server state detection method when executing the computer instructions.
According to a fourth aspect of embodiments of the present application, there is provided a computer-readable storage medium storing computer instructions which, when executed by a processor, implement the steps of the server state detection method.
The server state detection method comprises the steps of sending a state test request to a server to be detected; determining the communication state of the server to be detected according to state test information returned by the server to be detected in response to the state test request; sending a heartbeat request to the server to be detected, and determining the heartbeat state of the server to be detected according to the heartbeat information fed back by the server to be detected; and detecting the running state of the server to be detected according to the communication state and the heartbeat state. According to the embodiment of the application, the running state of the server to be detected is judged through different dimensions, and the normal running of subsequent services is ensured.
Drawings
Fig. 1 is a flowchart of a method for detecting a server status according to an embodiment of the present application;
FIG. 2 is an architecture diagram of a server detection method according to an embodiment of the present application;
fig. 3 is a processing flow diagram of a server state detection method applied to a live scenario according to an embodiment of the present application;
fig. 4 is a schematic structural diagram of a server status detection apparatus according to an embodiment of the present application;
fig. 5 is a block diagram of a computing device according to an embodiment of the present application.
Detailed Description
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present application. This application is capable of implementation in many different ways than those herein set forth and of similar import by those skilled in the art without departing from the spirit and scope of this application, and thus this application is not limited to the specific implementations disclosed below.
The terminology used in the one or more embodiments of the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of the present application. As used in one or more embodiments of the present application and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used in one or more embodiments of the present application refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It should be understood that, although the terms first, second, etc. may be used herein in one or more embodiments to describe various information, these information should not be limited by these terms. These terms are only used to distinguish one type of information from another. For example, a first can also be referred to as a second and, similarly, a second can also be referred to as a first without departing from the scope of one or more embodiments of the present application. The word "if," as used herein, may be interpreted as "at … …" or "at … …" or "in response to a determination," depending on the context.
First, the noun terms to which one or more embodiments of the present application relate are explained.
Live streaming: the transport stream of live audio/video data is a stable and continuous stream that can be transmitted over a network to viewers for viewing.
Live broadcasting and stream pulling: the live streaming refers to a process of pulling the live streaming from a source station specified by a user through a live streaming cloud platform.
Pushing flow: refers to the process of transmitting the data stream packaged in the acquisition phase to the live broadcast server.
DNS: domain Name System (Domain Name System), a Domain Name resolution service, i.e. a service for converting a Domain Name into an IP address, for example, accessing a website, requires querying an actual access address through a DNS, and then accessing the address, where a mapping relationship between a Domain Name and an IP address is 1 to many, and one Domain Name may correspond to a plurality of IP addresses.
CDN: content Delivery Network, i.e. a Content distribution Network.
CDN service provider: to provide a service of a content distribution network.
Edge computing node: a server for receiving the push stream.
SRT protocol: secure Reliable Transport (UDP), a UDP-based Transport protocol.
RTMP protocol: real Time Messaging Protocol, which shows a TCP-based Real Time Messaging Protocol.
TCP: transmission Control Protocol (TCP) is a connection-oriented, reliable transport layer communication Protocol based on byte stream, and can perform bidirectional data Transmission after establishing TCP connection.
In an existing live broadcast system, a heartbeat service and a stream pushing service are usually deployed on an edge computing node, the heartbeat service is used for reporting the running state of the current edge computing node to a central server, the stream pushing service is used for stream pushing and conversion pushing operations of live broadcast streams, and the heartbeat service and the stream pushing service are not interactive. If the heartbeat service fails and the push flow service is normal, the central server considers that the edge computing node is unavailable, and then the live flow is not dispatched to the edge computing node, so that the number of available edge computing nodes is reduced, and the service pressure is increased; if the push streaming service fails and the heartbeat service is normal, the central service area considers that the edge computing node is available and continues to schedule the live streaming, and the live streaming cannot be normally watched by the audience due to the push streaming service failure, so that the watching experience of the user is influenced.
Based on the above, in the present application, a server status detection method is provided, and the present application relates to a server status detection apparatus, a computing device, and a computer readable storage medium, which are described in detail in the following embodiments one by one.
Fig. 1 shows a flowchart of a server status detection method provided in an embodiment of the present application, where the method is applied to a central server, and specifically includes the following steps:
step 102: and sending a state test request to the server to be detected.
In the live broadcast provided by the application, edge computing nodes are deployed around the country and used for receiving live broadcast streams pushed by an anchor broadcast and then pushing the live broadcast streams to A Content Delivery Network server, A Content Delivery Network (CDN) is an advanced traffic distribution Network constructed on an existing Network, A new Network architecture is added to the existing Network, the Content of A website is distributed to the edge of the Network closest to A user, the response speed of the user for accessing the website is improved, and the CDN has the characteristic of load balancing.
The edge computing nodes receive the live stream to be processed pushed by the anchor, whether the edge computing nodes can normally operate or not affects the whole live broadcast system, if the edge computing nodes have problems, the anchor push stream and the watching of a user can be directly affected, therefore, the states of the edge computing nodes need to be monitored, and the edge computing nodes needing to be monitored are the servers to be detected.
In order to detect the operating state of the server to be detected, a state test request needs to be sent to the server to be detected, and specifically, the sending of the state test request to the server to be detected includes:
and sending a port test request and a plug flow test request to the server to be detected.
In practical application, a state test request is sent to a server to be detected, and the state test request is divided into two parts, namely a port test request and a plug flow test request.
In practical application, a stream pushing server receives a live stream, related server ports, such as an 80 port, an 81 port, a 1937 port and the like, need to be opened, if a stream pushing server code or a stream pushing service is abnormal, related service ports are not communicated, and an anchor can not carry out stream pushing, based on which, the related ports on a server to be detected need to be tested, and a port test request is mainly used for testing whether the service ports of the server to be detected are normal. Specifically, a connection request carrying timeout time, for example, a TCP connection request carrying timeout time, is sent to a relevant service port of the server to be detected, where the connection request is used to request to establish a connection between the central server and the server to be detected.
In the existing live broadcast system, the situations of the exception of the push flow protocol and the exception of the program code for receiving the push flow service usually occur. The push flow Protocol is generally divided into an SRT Protocol (Secure Reliable Transport Protocol) and an RTMP Protocol (Real Time Messaging Protocol), when a central server schedules an edge computing node of a push flow for a main broadcast, the central server may designate a corresponding push flow Protocol, and if a certain Protocol of the edge computing node is configured incorrectly or is out of service, the Protocol may not receive the push flow, resulting in a failure of the main broadcast push flow; in practical application, after the edge computing node receives the push flow, the push flow is pushed to each CDN, a user obtains a live stream from a server pull-up stream of each CDN to watch the live stream, if the service code on the edge computing node is abnormal, the live stream cannot be pushed to each CDN, the user cannot normally pull the stream to watch the live stream, and normal use of the user is affected. Therefore, it is also necessary to send a plug flow test request to the server to be detected.
Specifically, sending a plug flow test request to a server to be detected includes:
pushing a first multimedia stream to the server to be detected through a first protocol, and pushing a second multimedia stream to the server to be detected through a second protocol;
establishing a communication connection with a content distribution network;
the first multimedia stream is pulled from between the content distribution networks according to the first protocol and the communication connection, and the second multimedia stream is pulled from between the content distribution networks according to the second protocol and the communication connection.
The first protocol and the second protocol are respectively two commonly used push flow protocols, for example, if the first protocol is an SRT protocol, the second protocol is an RTMP protocol; if the first protocol is the RTMP protocol, the second protocol is the SRT protocol.
Whether a stream pushing protocol and a program code for receiving a stream pushing service deployed on an edge computing node are normal or not cannot be found through fixed data acquisition or heartbeat report, and only when a main broadcast initiates a stream pushing, the stream pushing protocol can be triggered, if the main broadcast finds that the program code is abnormal during the direct broadcasting, the normal use of a user is influenced.
Specifically, firstly, a main broadcast is simulated, a first multimedia stream is sent to a server to be detected through a first protocol, a second multimedia stream is sent to the server to be detected through a second protocol, and the server to be detected pushes the first multimedia stream and the second multimedia stream to a CDN server; simulating audience, initiating a connection establishment request to the CDN service, establishing communication connection with the CDN, pulling a first multimedia stream from the CDN server through the communication connection according to a first protocol, pulling a second multimedia stream from the CDN server through the communication connection according to a second protocol, and completing simulation test of the whole process of the direct-broadcast and direct-flow-pull in an automatic simulation and direct-flow-pull test mode to judge whether a program code of a direct-flow protocol or receiving the direct-flow service is normal or not.
Step 104: and determining the communication state of the server to be detected according to the state test information returned by the server to be detected in response to the state test request.
After the state test request is sent to the server to be detected, the server to be detected can respond to the state test request to generate a corresponding state test result and return the state test result to the central server, and the central server determines the communication state of the server to be detected according to the state test result.
In practical application, the status test request specifically includes a port test request and a plug-flow test request, the server to be detected returns a corresponding test result according to each test request, and specifically, the communication status of the server to be detected is determined according to the status test information returned by the server to be detected in response to the status test request, which includes S1042-S1046:
s1042, determining the port running state of the server to be detected according to the port test information returned by the server to be detected in response to the port test request.
Determining the port operating state of the server to be detected according to port test information returned by the server to be detected in response to the port test request, wherein the determining comprises the following steps:
judging whether port test information returned by the server to be detected in response to the port test request is received;
if so, determining that the running state of the port of the server to be detected is normal;
and if not, determining that the running state of the port of the server to be detected is abnormal.
The port test request is a connection request carrying overtime time, and if the server to be detected is successfully connected within the overtime time and a successful connection result is returned, the running state of the port of the server to be detected is determined to be normal and the port is available; if the server to be detected is not successfully connected within the overtime time, and connection overtime is displayed, it is indicated that the running state of the port of the server to be detected is abnormal, and the port is unavailable.
In a specific embodiment provided by the application, if the IP address of the server a to be detected is 1.1.1.1, and the ports to be tested are 80 and 1937, a TCP connection request is sent to the following ports, 1.1.1.1 and 1.1.1.1, 1937, and the configured timeout time is 3 seconds, if response information returned by the server a to be detected is received within 3 seconds, it is indicated that the two ports are normal, otherwise, it is indicated that the ports are abnormal.
And S1044, determining the push flow running state of the server to be detected according to the push flow test information returned by the server to be detected in response to the push flow test request.
Determining the push flow running state of the server to be detected according to the push flow test information returned by the server to be detected in response to the push flow test request, wherein the determining comprises the following steps:
determining that the stream pushing running state of the server to be detected is normal under the condition that the state of pulling the first multimedia stream is normal and the state of pulling the second multimedia stream is normal;
and determining that the push flow running state of the server to be detected is abnormal under the condition that the state of pulling the first multimedia flow is abnormal and/or the state of pulling the second multimedia flow is abnormal.
The central server pushes a first multimedia stream to the server to be detected through a first protocol, pushes a second multimedia stream to the server to be detected through a second protocol, pulls the first multimedia stream through the CDN through the first protocol, and pulls the second multimedia stream through the CDN through the second protocol. If the first protocol and the second protocol can both pull the stream normally, it indicates that the push stream running state of the server to be detected is normal.
If one of the first protocol or the second protocol can normally pull the stream, it indicates that the stream pushing running state of the server to be detected is abnormal, and at the same time, it can be determined which protocol is available, for example, if the stream can be normally pulled through the SRT protocol, but the stream cannot be normally pulled through the RTMP protocol, it indicates that the stream pushing running state of the server to be detected is abnormal, the SRT protocol is available, and if the stream can be normally pulled through the RTMP protocol, but the stream cannot be normally pulled through the SRT protocol, it indicates that the stream pushing running state of the server to be detected is abnormal, and the RTMP protocol is available.
And if the first protocol and the second protocol can not normally pull the flow, indicating that the push flow running state of the server to be detected is abnormal.
S1046, determining the communication state of the server to be detected according to the port running state and the plug flow running state.
After the port running state and the plug flow running state of the server to be detected are obtained, the communication state of the server to be detected can be determined according to the port running state and the plug flow running state.
Specifically, the running state of the port is normal or abnormal, and the plug flow running state is normal or abnormal;
determining the communication state of the server to be detected according to the port operation state and the plug flow operation state, including:
determining that the communication state of the server to be detected is normal under the condition that the port operation state is normal and the plug flow operation state is normal;
and determining that the communication state of the server to be detected is abnormal under the condition that the port operation state is abnormal or the plug flow operation state is abnormal.
And under the condition that the port running state and the plug flow running state are both normal, determining that the communication state of the server to be detected is normal.
Determining that the communication state of the server to be detected is abnormal under the condition that any one of the port operation state and the plug flow operation state is abnormal, and at the moment, if the port operation state is abnormal, the server to be detected is unavailable; if the plug-flow running state is abnormal and under the condition that a certain protocol is available, the communication state of the server to be detected is still available although the communication state is abnormal; and if the plug flow running state is abnormal and no protocol is available, indicating that the communication state of the server to be detected is abnormal.
Step 106: and sending a heartbeat request to the server to be detected, and determining the heartbeat state of the server to be detected according to the heartbeat information fed back by the server to be detected.
The heartbeat request is to one of the two interconnected parties, a small data packet is sent to the other party at fixed time intervals, and whether the communication link between the two interconnected parties is disconnected or not is judged according to the reply condition of the other party. The heartbeat request is used for determining whether the two interconnected parties are on-line or not under the condition that the two interconnected parties do not communicate for a long time or whether the communication link between the two interconnected parties is still connected. In the application, a center server sends a heartbeat request to a server to be detected, the server to be detected responds to the heartbeat request to feed back heartbeat information, and the center server judges whether the server to be detected is available online according to the heartbeat information fed back by the server to be detected.
When the central server cannot receive the heartbeat information fed back by the server to be detected, the server to be detected is considered to be abnormal, the server to be detected is not used any more, but sometimes the heartbeat service in the server to be detected is abnormal, the plug-flow service in the server to be detected can be normally used, and if the server to be detected is removed from the scheduling list only because the heartbeat information fed back by the server to be detected is not received, the normal live broadcast service can be influenced. Therefore, determining the heartbeat state of the server to be detected according to the heartbeat information fed back by the server to be detected specifically includes:
determining an available server list according to the heartbeat information fed back by the server to be detected;
and determining the heartbeat state of the server to be detected according to the available server list and an available server list of a checking center server, wherein the checking center server is a center server which is used for receiving the heartbeat information of the server to be detected and is not the center server in a center server cluster where the center server is located.
Determining an available server list according to the heartbeat information fed back by the server to be detected, wherein the determining comprises the following steps:
counting the quantity of heartbeat information received in a current preset time period;
and determining an available server list according to the quantity of the heartbeat information in the current preset time period and the quantity of the heartbeat information in the last preset time period.
The central server receives and counts the quantity of the heartbeat information received and reported by each edge computing node in each preset time period, and records each edge computing node successfully reporting the heartbeat information in an available server list, wherein the available server list is used for recording the identification of the currently available edge computing node.
Assuming that the quantity of heartbeat information received in the current preset time period is counted as B, the quantity of heartbeat information received in the last preset time period is counted as A, and the heartbeat information variation is calculated by the following formula 1:
c = (A-B)/A formula 1
Wherein, C represents the variation of the heartbeat information, a is the number of the heartbeat information received in the last preset time period, and B is the number of the heartbeat information received in the current preset time period.
If C is greater than the preset threshold, it indicates that a large number of edge computing nodes are offline in a short time, and it is probably that the heartbeat service is in a reporting period this time, and the push streaming service can be normally used.
If C is less than or equal to a preset threshold value, the heartbeat service is considered to be normal, and the edge computing nodes which cannot normally report the heartbeat information are in an abnormal state, the available server list is updated according to the edge computing nodes which receive the heartbeat information in the current preset time period, and the edge computing nodes which cannot report the heartbeat information are removed from the available server list.
Determining the heartbeat state of the server to be detected according to the available server list and the available server list of the checking center server, wherein the determining comprises the following steps:
acquiring an available server list of at least one check center server in a center server cluster where the center server is located;
and determining the heartbeat state of the server to be detected according to the available server list of the current central server and the available server list of the at least one checking central server.
The checking center server is a center server except the center server in the center server cluster, in practical application, the server to be detected sends heartbeat information to the center server and the checking center server, and the heartbeat information is transmitted through multiple links, so that the risk of abnormity in the process of transmitting the heartbeat information through a single link is reduced. The central server and the checking central server are usually servers deployed in different machine rooms and receiving heartbeat services reported by the server to be detected, and related transmission links and data storage are independent of each other.
The server to be detected sends heartbeat information to the central server and the checking central server simultaneously, the central server and the checking central server respectively store data, then the central server acquires an available server list of the checking central server from the checking central server, compares the available server list of the current central server with the available server list in the checking central server, and can determine the heartbeat state of the server to be detected according to the comparison result.
Specifically, determining the heartbeat state of the server to be detected according to the available server list of the current central server and the available server list of the at least one checking central server includes:
judging whether the server to be detected exists in an available server list of the central server or not;
if so, determining that the heartbeat state of the server to be detected is normal;
if not, judging whether the server to be detected exists in an available server list of the at least one checking center server;
if so, determining that the heartbeat state of the server to be detected is normal and the connection between the server to be detected and the central server is abnormal;
if not, determining that the heartbeat state of the server to be detected is abnormal.
Firstly, judging whether a server identification to be detected corresponding to the server to be detected exists in an available server list of a current central server, if so, indicating that heartbeat information of the server to be detected is received, determining that the heartbeat state of the server to be detected is normal, if not, further checking whether the server identification to be detected of the server to be detected exists in an available server list of a checking central server, if so, indicating that the checking central server receives the heartbeat information of the server to be detected, determining that the heartbeat state of the server to be detected is normal, and if not, indicating that the server to be detected cannot normally send the heartbeat information, and further determining that the heartbeat state of the server to be detected is abnormal.
Step 108: and detecting the running state of the server to be detected according to the communication state and the heartbeat state.
And finally, determining the running state of the server to be detected by combining the communication state and the heartbeat state of the server to be detected.
Specifically, the communication state is normal or abnormal, and the heartbeat state is normal or abnormal;
detecting the running state of the server to be detected according to the communication state and the heartbeat state, wherein the detecting comprises the following steps:
determining that the running state of the server to be detected is normal under the condition that the communication state is normal and the heartbeat state is normal;
and determining that the running state of the server to be detected is abnormal under the condition that the communication state is abnormal or the heartbeat state is abnormal.
And under the condition that the communication state is normal and the heartbeat state is normal, determining that the running state of the server to be detected is normal, namely the server to be detected can be normally used.
And under the condition that at least one of the communication state or the heartbeat state is abnormal, determining that the operation state of the server to be detected is abnormal, and the server to be detected cannot be normally used.
The server state detection method comprises the steps of sending a state test request to a server to be detected; determining the communication state of the server to be detected according to state test information returned by the server to be detected in response to the state test request; sending a heartbeat request to the server to be detected, and determining the heartbeat state of the server to be detected according to heartbeat information fed back by the server to be detected; and detecting the running state of the server to be detected according to the communication state and the heartbeat state. According to the embodiment of the application, the operation state of the server to be detected is judged through different dimensions, only after the test of each dimension is successful, the operation state of the server to be detected can be determined to be normal, and the normal operation of subsequent services can be effectively guaranteed.
In the following, with reference to fig. 2 and fig. 3, the server state detection method provided by the present application is further described by taking an application of the server state detection method in a live scene as an example. Fig. 2 shows an architecture diagram of the server detection method provided in an embodiment of the present application, and as shown in fig. 2, the anchor pushes a live stream to a receiving stream pushing service in a server 204 to be detected, the receiving stream pushing service pushes the live stream to the CDN, and a viewer pulls the live stream to a client through the CDN for viewing.
In the server state detection method provided by the application, the heartbeat service in the server to be detected 204 feeds back heartbeat information to the central server through the reported heartbeat line 1, the heartbeat information is fed back to the checking central server through the reported heartbeat line 2, the available server list is determined in the central server, the available server list is determined in the checking central server, the central server acquires the available server list of the checking central server from the checking central server for comparison, and then the heartbeat state of the server to be detected 204 is determined.
Meanwhile, the central server sends a port test request and a plug flow test request to the server 204 to be detected, determines a port running state and a plug flow running state of the server to be detected according to the port test information and the plug flow test information returned by the server 204 to be detected, and further determines a communication state of the server 204 to be detected according to the port running state and the plug flow running state.
And finally, determining the running state of the server to be detected 204 according to the heartbeat state and the communication state of the server to be detected 204.
Fig. 3 shows a processing flow chart of a server state detection method applied to a live broadcast scenario, which specifically includes the following steps:
step 302: and counting the quantity of the heartbeat information received in the current preset time period.
In a specific embodiment provided by the present application, taking the edge computing node M as an example, where the edge computing node M is a server to be detected, the heartbeat information quantity a reported by all edge computing nodes in a preset time period is counted.
Step 304: and determining an available server list according to the quantity of the heartbeat information in the current preset time period and the quantity of the heartbeat information in the last preset time period.
In a specific embodiment provided by the present application, following the above example, the number of heartbeat messages received in the last preset time period and reported by all edge computing nodes is B, and after the number of heartbeat messages a in the current time period and the number of heartbeat messages B in the last preset time period, the List1 of available servers may be determined. The available edge compute node identities are stored in List1.
Step 306: and acquiring an available server list of at least one check center server in a center server cluster in which the center server is positioned.
In an embodiment provided by the present application, following the above example, the List of available servers List2 of the checking center server in the center server cluster is obtained.
Step 308: and determining the heartbeat state of the server to be detected according to the available server list of the current central server and the available server list of the at least one checking central server.
In a specific embodiment provided by the present application, the above example is continued, and whether the to-be-detected server identifier of the to-be-detected server M exists in List1 or List2 is queried, and after the query, the to-be-detected server identifier of the to-be-detected server M is respectively stored in List1 and List2, and it is determined that the heartbeat state of the to-be-detected server M is normal.
Step 310: and sending a port test request to the server to be detected.
In a specific embodiment provided by the present application, the port test request is sent to the 80 ports of the to-be-detected server M along the above example.
Step 312: and determining the port running state of the server to be detected according to the port test information returned by the server to be detected in response to the port test request.
In a specific embodiment provided by the present application, the above example is continued, and the response information returned by the server M to be detected is received, and the port operation state of the server M to be detected is determined to be normal.
Step 314: and sending a plug flow test request to the server to be detected.
In a specific embodiment provided by the present application, along with the above example, the first test live stream is sent to the server M to be detected through the SRT protocol, and the second test live stream is sent to the server M to be detected through the RTMP protocol. And then establishing communication connection with the target CDN, pulling a first test live stream from the target CDN through an SRT protocol, and pulling a second test live stream from the target CDN through an RTMP protocol.
Step 316: and determining the plug-flow running state of the server to be detected according to the plug-flow test information returned by the server to be detected in response to the plug-flow test request.
In a specific embodiment provided by the present application, following the above example, if the first test live stream is successfully pulled through the SRT protocol, and the second test live stream is successfully pulled through the RTMP protocol, it may be determined that the push stream operating state of the server M to be detected is normal.
Step 318: and detecting the running state of the server to be detected according to the heartbeat state, the port running state and the plug flow running state of the server to be detected.
In a specific embodiment provided by the present application, the above example is used, the heartbeat state of the server M to be detected is normal, the port operation state is normal, and the plug flow operation state is normal, so that the operation state of the server M to be detected is normal.
It should be noted that, in the server state detection method provided in the present application, steps 302 to 308 are steps of a detection method for detecting a heartbeat state of a server to be detected; steps 310 to 312 are the steps of the method for detecting the running state of the port of the server to be detected; steps 314 to 316 are the steps of the method for detecting the plug-flow running state of the server to be detected. The heartbeat state, the port running state and the plug flow running state are not necessarily in sequence, the execution sequence can be determined according to practical application, some unavailable servers to be detected can be filtered after each detection, and the detection efficiency is improved.
The server state detection method comprises the steps of sending a state test request to a server to be detected; determining the communication state of the server to be detected according to state test information returned by the server to be detected in response to the state test request; sending a heartbeat request to the server to be detected, and determining the heartbeat state of the server to be detected according to the heartbeat information fed back by the server to be detected; and detecting the running state of the server to be detected according to the communication state and the heartbeat state. According to the embodiment of the application, the operation state of the server to be detected is judged through different dimensions, only after the test of each dimension is successful, the operation state of the server to be detected can be determined to be normal, and the normal operation of subsequent services can be effectively guaranteed.
Corresponding to the above embodiment of the server state detection method, the present application further provides an embodiment of a server state detection apparatus applied to a central server, and fig. 4 shows a schematic structural diagram of a server state detection apparatus provided in an embodiment of the present application. As shown in fig. 4, the apparatus includes:
a sending module 402 configured to send a status test request to a server to be tested;
a first determining module 404, configured to determine a communication state of the server to be detected according to state test information returned by the server to be detected in response to the state test request;
a second determining module 406, configured to send a heartbeat request to the server to be detected, and determine a heartbeat state of the server to be detected according to the heartbeat information fed back by the server to be detected;
a detecting module 408 configured to detect an operating state of the server to be detected according to the communication state and the heartbeat state.
Optionally, the sending module 402 is further configured to:
and sending a port test request and a plug flow test request to the server to be detected.
Optionally, the first determining module 404 is further configured to:
determining the port running state of the server to be detected according to port test information returned by the server to be detected in response to the port test request;
determining the push flow running state of the server to be detected according to the push flow test information returned by the server to be detected in response to the push flow test request;
and determining the communication state of the server to be detected according to the port operation state and the plug flow operation state.
Optionally, the first determining module 404 is further configured to:
pushing a first multimedia stream to the server to be detected through a first protocol, and pushing a second multimedia stream to the server to be detected through a second protocol;
establishing a communication connection with a content distribution network;
the first multimedia stream is pulled from between the content distribution networks according to the first protocol and the communication connection, and the second multimedia stream is pulled from between the content distribution networks according to the second protocol and the communication connection.
Optionally, the first determining module 404 is further configured to:
determining that the stream pushing running state of the server to be detected is normal under the condition that the state of pulling the first multimedia stream is normal and the state of pulling the second multimedia stream is normal;
and determining that the push flow running state of the server to be detected is abnormal under the condition that the state of pulling the first multimedia flow is abnormal and/or the state of pulling the second multimedia flow is abnormal.
Optionally, the first determining module 404 is further configured to:
judging whether port test information returned by the server to be detected in response to the port test request is received;
if so, determining that the running state of the port of the server to be detected is normal;
if not, determining that the running state of the port of the server to be detected is abnormal.
Optionally, the port running state is normal or abnormal, and the plug flow running state is normal or abnormal;
optionally, the first determining module 404 is further configured to:
determining that the communication state of the server to be detected is normal under the condition that the port operation state is normal and the plug flow operation state is normal;
and determining that the communication state of the server to be detected is abnormal under the condition that the port operation state is abnormal or the plug flow operation state is abnormal.
Optionally, the second determining module 406 is further configured to:
counting the quantity of heartbeat information received in a current preset time period;
determining an available server list according to the quantity of heartbeat information in the current preset time period and the quantity of heartbeat information in the last preset time period;
acquiring an available server list of at least one checking center server in a center server cluster where the center server is located, wherein the checking center server is a center server which is used for receiving heartbeat information of the server to be detected and is except the center server in the center server cluster;
and determining the heartbeat state of the server to be detected according to the available server list of the current central server and the available server list of the at least one checking central server.
Optionally, the second determining module 406 is further configured to:
judging whether the server to be detected exists in an available server list of the central server or not;
if so, determining that the heartbeat state of the server to be detected is normal;
if not, judging whether the server to be detected exists in an available server list of the check center server;
if so, determining that the heartbeat state of the server to be detected is normal and the connection between the server to be detected and the central server is abnormal;
and if not, determining that the heartbeat state of the server to be detected is abnormal.
Optionally, the communication state is normal or abnormal, and the heartbeat state is normal or abnormal;
the detection module 408 is further configured to:
determining that the running state of the server to be detected is normal under the condition that the communication state is normal and the heartbeat state is normal;
and determining that the running state of the server to be detected is abnormal under the condition that the communication state is abnormal or the heartbeat state is abnormal.
The server state detection device comprises a state test request sending unit, a state test unit and a state test unit, wherein the state test request is sent to a server to be detected; determining the communication state of the server to be detected according to state test information returned by the server to be detected in response to the state test request; sending a heartbeat request to the server to be detected, and determining the heartbeat state of the server to be detected according to the heartbeat information fed back by the server to be detected; and detecting the running state of the server to be detected according to the communication state and the heartbeat state. According to the embodiment of the application, the running state of the server to be detected is judged according to different dimensions, and the running state of the server to be detected can be determined to be normal only after the test of each dimension is successful, so that the normal running of subsequent services can be effectively ensured.
The above is a schematic scheme of a server status detection apparatus according to this embodiment. It should be noted that the technical solution of the server state detection apparatus and the technical solution of the server state detection method belong to the same concept, and details that are not described in detail in the technical solution of the server state detection apparatus can be referred to the description of the technical solution of the server state detection method.
Fig. 5 illustrates a block diagram of a computing device 500 provided according to an embodiment of the present application. The components of the computing device 500 include, but are not limited to, a memory 510 and a processor 520. Processor 520 is coupled to memory 510 via bus 530, and database 550 is used to store data.
Computing device 500 also includes access device 540, access device 540 enabling computing device 500 to communicate via one or more networks 560. Examples of such networks include the Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the internet. The access device 540 may include one or more of any type of network interface, e.g., a Network Interface Card (NIC), wired or wireless, such as an IEEE802.11 Wireless Local Area Network (WLAN) wireless interface, a worldwide interoperability for microwave access (Wi-MAX) interface, an ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a bluetooth interface, a Near Field Communication (NFC) interface, and so forth.
In one embodiment of the application, the above-described components of computing device 500 and other components not shown in FIG. 5 may also be connected to each other, such as by a bus. It should be understood that the block diagram of the computing device illustrated in FIG. 5 is for purposes of example only and is not intended to limit the scope of the present application. Those skilled in the art may add or replace other components as desired.
Computing device 500 may be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., tablet, personal digital assistant, laptop, notebook, netbook, etc.), mobile phone (e.g., smartphone), wearable computing device (e.g., smartwatch, smartglasses, etc.), or other type of mobile device, or a stationary computing device such as a desktop computer or PC. Computing device 500 may also be a mobile or stationary server.
Wherein, the processor 520 implements the steps of the server status detection method when executing the computer instructions.
The above is an illustrative scheme of a computing device of the present embodiment. It should be noted that the technical solution of the computing device and the technical solution of the server state detection method belong to the same concept, and for details that are not described in detail in the technical solution of the computing device, reference may be made to the description of the technical solution of the server state detection method.
An embodiment of the present application further provides a computer readable storage medium, which stores computer instructions, and the computer instructions, when executed by a processor, implement the steps of the server state detection method as described above.
The above is an illustrative scheme of a computer-readable storage medium of the present embodiment. It should be noted that the technical solution of the storage medium belongs to the same concept as the technical solution of the above-mentioned server state detection method, and details that are not described in detail in the technical solution of the storage medium can be referred to the description of the technical solution of the above-mentioned server state detection method.
The foregoing description has been directed to specific embodiments of this application. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
The computer instructions comprise computer program code which may be in source code form, object code form, an executable file or some intermediate form, or the like. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, usb disk, removable hard disk, magnetic disk, optical disk, computer Memory, read-Only Memory (ROM), random Access Memory (RAM), electrical carrier wave signals, telecommunications signals, software distribution medium, and the like. It should be noted that the computer-readable medium may contain suitable additions or subtractions depending on the requirements of legislation and patent practice in jurisdictions, for example, in some jurisdictions, computer-readable media may not include electrical carrier signals or telecommunication signals in accordance with legislation and patent practice.
It should be noted that, for the sake of simplicity, the above-mentioned method embodiments are described as a series of acts or combinations, but those skilled in the art should understand that the present application is not limited by the described order of acts, as some steps may be performed in other orders or simultaneously according to the present application. Further, those skilled in the art will appreciate that the embodiments described in this specification are presently considered to be preferred embodiments and that acts and modules are not required in the present application.
In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.
The preferred embodiments of the present application disclosed above are intended only to aid in the explanation of the application. Alternative embodiments are not exhaustive and do not limit the invention to the precise embodiments described. Obviously, many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the application and its practical applications, to thereby enable others skilled in the art to best understand and utilize the application. The application is limited only by the claims and their full scope and equivalents.
Claims (11)
1. A server state detection method is applied to a central server and comprises the following steps:
sending a port test request and a plug flow test request to a server to be detected;
determining the port running state of the server to be detected according to port test information returned by the server to be detected in response to the port test request;
determining the push flow running state of the server to be detected according to the push flow test information returned by the server to be detected in response to the push flow test request;
determining the communication state of the server to be detected according to the port operation state and the plug flow operation state;
sending a heartbeat request to the server to be detected, and counting the quantity of heartbeat information received in the current preset time period;
determining an available server list according to the quantity of heartbeat information in the current preset time period and the quantity of heartbeat information in the last preset time period;
determining the heartbeat state of the server to be detected according to the available server list and an available server list of a checking center server, wherein the checking center server is a center server which is used for receiving heartbeat information of the server to be detected and is not the center server in a center server cluster where the center server is located;
and detecting the running state of the server to be detected according to the communication state and the heartbeat state.
2. The method for detecting the state of the server according to claim 1, wherein sending a push flow test request to the server to be detected comprises:
pushing a first multimedia stream to the server to be detected through a first protocol, and pushing a second multimedia stream to the server to be detected through a second protocol;
establishing a communication connection with a content distribution network;
the first multimedia stream is pulled from between the content distribution networks according to the first protocol and the communication connection, and the second multimedia stream is pulled from between the content distribution networks according to the second protocol and the communication connection.
3. The method for detecting the state of the server according to claim 2, wherein determining the push flow running state of the server to be detected according to the push flow test information returned by the server to be detected in response to the push flow test request comprises:
determining that the stream pushing running state of the server to be detected is normal under the condition that the state of pulling the first multimedia stream is normal and the state of pulling the second multimedia stream is normal;
and under the condition that the state of pulling the first multimedia stream is abnormal and/or the state of pulling the second multimedia stream is abnormal, determining that the push flow running state of the server to be detected is abnormal.
4. The method for detecting the state of the server according to claim 1, wherein determining the port operating state of the server to be detected according to the port test information returned by the server to be detected in response to the port test request comprises:
judging whether port test information returned by the server to be detected in response to the port test request is received;
if so, determining that the running state of the port of the server to be detected is normal;
and if not, determining that the running state of the port of the server to be detected is abnormal.
5. The server state detection method according to claim 1, wherein the port operating state is normal or abnormal, and the plug flow operating state is normal or abnormal;
determining the communication state of the server to be detected according to the port operation state and the plug flow operation state, including:
determining that the communication state of the server to be detected is normal under the condition that the port operation state is normal and the plug flow operation state is normal;
and determining that the communication state of the server to be detected is abnormal under the condition that the port operation state is abnormal and/or the plug flow operation state is abnormal.
6. The method for detecting the status of the server according to claim 1, wherein determining the status of the heartbeat of the server to be detected according to the available server list and the available server list of the checking center server comprises:
acquiring an available server list of at least one check center server in a center server cluster in which the center server is positioned;
and determining the heartbeat state of the server to be detected according to the available server list of the current central server and the available server list of the at least one checking central server.
7. The method for detecting the status of a server according to claim 6, wherein determining the heartbeat status of the server to be detected according to the available server list of the current central server and the available server list of the at least one checking central server comprises:
judging whether the server to be detected exists in an available server list of the central server or not;
if so, determining that the heartbeat state of the server to be detected is normal;
if not, judging whether the server to be detected exists in an available server list of the at least one checking center server;
if so, determining that the heartbeat state of the server to be detected is normal and the connection between the server to be detected and the central server is abnormal;
and if not, determining that the heartbeat state of the server to be detected is abnormal.
8. The server state detection method according to any one of claims 1 to 7, wherein the communication state is normal or abnormal, and the heartbeat state is normal or abnormal;
detecting the running state of the server to be detected according to the communication state and the heartbeat state, wherein the detecting comprises the following steps:
determining that the running state of the server to be detected is normal under the condition that the communication state is normal and the heartbeat state is normal;
and determining that the running state of the server to be detected is abnormal under the condition that the communication state is abnormal and/or the heartbeat state is abnormal.
9. A server state detection device is applied to a central server and comprises:
the sending module is configured to send a port test request and a flow pushing test request to the server to be detected;
the first determining module is configured to determine the port running state of the server to be detected according to port test information returned by the server to be detected in response to the port test request; determining the push flow running state of the server to be detected according to the push flow test information returned by the server to be detected in response to the push flow test request; determining the communication state of the server to be detected according to the port operation state and the plug flow operation state;
the second determining module is configured to send a heartbeat request to the server to be detected and count the quantity of heartbeat information received in a current preset time period; determining an available server list according to the quantity of heartbeat information in the current preset time period and the quantity of heartbeat information in the last preset time period; determining the heartbeat state of the server to be detected according to the available server list and an available server list of a checking center server, wherein the checking center server is a center server which is used for receiving heartbeat information of the server to be detected and is not the center server in a center server cluster where the center server is located;
and the detection module is configured to detect the running state of the server to be detected according to the communication state and the heartbeat state.
10. A computing device comprising a memory, a processor, and computer instructions stored on the memory and executable on the processor, wherein the processor implements the steps of the method of any one of claims 1-8 when executing the computer instructions.
11. A computer-readable storage medium storing computer instructions, which when executed by a processor, perform the steps of the method of any one of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110423303.4A CN113032223B (en) | 2021-04-20 | 2021-04-20 | Server state detection method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110423303.4A CN113032223B (en) | 2021-04-20 | 2021-04-20 | Server state detection method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113032223A CN113032223A (en) | 2021-06-25 |
| CN113032223B true CN113032223B (en) | 2023-04-11 |
Family
ID=76457709
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110423303.4A Active CN113032223B (en) | 2021-04-20 | 2021-04-20 | Server state detection method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113032223B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114172829B (en) * | 2022-02-10 | 2022-08-12 | 统信软件技术有限公司 | Server health monitoring method and system and computing equipment |
| CN114726764A (en) * | 2022-06-08 | 2022-07-08 | 广东迅维信息产业股份有限公司 | Business service disaster recovery method and system |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107979820A (en) * | 2016-10-25 | 2018-05-01 | 腾讯科技（北京）有限公司 | A kind of method and device, equipment for testing PUSH message |
| CN109660380A (en) * | 2018-09-28 | 2019-04-19 | 深圳壹账通智能科技有限公司 | Monitoring method, platform, system and the readable storage medium storing program for executing of operation condition of server |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103560922A (en) * | 2013-11-18 | 2014-02-05 | 北京特立信电子技术股份有限公司 | Disaster recovery method and system |
| CN113285864B (en) * | 2015-01-28 | 2022-10-04 | 安博科技有限公司 | System and method for global virtual network |
| CN110225021A (en) * | 2019-06-04 | 2019-09-10 | 秒针信息技术有限公司 | Live network broadcast method and device |
| CN111176873A (en) * | 2019-12-20 | 2020-05-19 | 中国平安财产保险股份有限公司 | Micro-service automatic offline method and device, computer equipment and storage medium |
| CN111414230A (en) * | 2020-03-18 | 2020-07-14 | 北京达佳互联信息技术有限公司 | Service management system, service management method, server, and storage medium |
-
2021
- 2021-04-20 CN CN202110423303.4A patent/CN113032223B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107979820A (en) * | 2016-10-25 | 2018-05-01 | 腾讯科技（北京）有限公司 | A kind of method and device, equipment for testing PUSH message |
| CN109660380A (en) * | 2018-09-28 | 2019-04-19 | 深圳壹账通智能科技有限公司 | Monitoring method, platform, system and the readable storage medium storing program for executing of operation condition of server |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113032223A (en) | 2021-06-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8320257B2 (en) | Automatic testing of scheduled telepresence meetings | |
| CN113032223B (en) | Server state detection method and device | |
| US11218382B2 (en) | Quality of service monitoring method, device, and system | |
| CN113055693B (en) | Data processing method and device | |
| CN108810657B (en) | Method and system for setting video cover | |
| CN113301299B (en) | Multi-channel video transmission method, system, terminal and storage medium | |
| CN109995839B (en) | Load balancing method, system and load balancer | |
| CN103312593B (en) | A kind of message distributing system and method | |
| CN113923470A (en) | Live stream processing method and device | |
| CN113422728A (en) | Method and device for selecting content distribution network link | |
| CN114679604A (en) | Resource processing method and device | |
| CN108650482B (en) | Response method and device for video call service | |
| CN110113558B (en) | Data processing method, device, system and computer readable storage medium | |
| CN112187486A (en) | Interaction method between intelligent devices and intelligent devices | |
| CN110149365B (en) | Service adaptation method, device, system and computer readable medium | |
| US20140200041A1 (en) | Evaluation of overall performance of interactive application service | |
| CN107071038B (en) | Method and device for transmitting multimedia data | |
| CN115632815A (en) | Data updating method and device, electronic equipment and storage medium | |
| CN114760490A (en) | Video stream processing method and device | |
| US9485458B2 (en) | Data processing method and device | |
| CN110753071B (en) | Information acquisition method and device | |
| CN113301100A (en) | Data disaster tolerance method, device, equipment and medium based on content distribution network | |
| CN112312094B (en) | Method and device for processing media information, storage medium and electronic device | |
| CN114363665B (en) | Multi-service code stream pushing method, system, computer equipment and storage medium | |
| CN111131753B (en) | Conference processing method and conference management platform server |
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 |