Long connection state pushing method and system based on server sending event heartbeat keep-alive

Abstract

The application relates to the field of distributed systems and real-time communication technology, and particularly discloses a long-connection state pushing method and system based on server-sent event heartbeat keep-alive, which comprises the following steps: in response to a heartbeat request of a client, updating a heartbeat timestamp of a long connection corresponding to the client; judging whether the long connection is in an abnormal state according to a time difference between the heartbeat timestamp and a current time; when it is judged that the long connection is in the abnormal state, sending a reconnection instruction to the client, so that the client rebuilds the long connection based on the reconnection instruction; and during a period when the long connection is in a normal state, pushing event data to the client through the long connection.

Description

Technical Field

[0001] This invention relates to the field of distributed systems and real-time communication technology, specifically to a long-connection status push method and system based on server-sent event heartbeat keep-alive. Background Technology

[0002] Server-Sent Events (SSE) is a one-way streaming protocol based on persistent HTTP connections. The server can continuously push event data to the client through a persistent HTTP connection, eliminating the need for repeated requests from the client. Because SSE technology can maintain the connection and continuously receive data from the server, it overcomes the shortcomings of traditional HTTP's response-based communication and has been widely used in scenarios with high real-time requirements, such as real-time monitoring, message pushing, and live video streaming.

[0003] In practical applications of SSE long-lived connections, connection keep-alive is a key technical issue for ensuring continuous service availability. Since SSE connections can last for hours or even days, network intermediary devices (such as NAT gateways, proxy servers, and firewalls) may actively disconnect idle connections due to prolonged periods without data transmission. To maintain the liveness of long-lived connections, existing technologies typically employ a method where the client periodically sends heartbeat packets to keep the connection alive—the client starts a timer and sends heartbeat data packets to the server at fixed intervals to ensure that the connection between the server and the client is not broken due to idleness. Furthermore, some solutions also incorporate a timeout reconnection mechanism on the server side; when an SSE long-lived connection is detected as broken, the client recreates the connection object and re-establishes the SSE long-lived connection with the server.

[0004] However, existing long-connection keep-alive solutions have the following shortcomings: First, there is a lag in abnormal state detection. In existing solutions, heartbeat keep-alive is usually initiated unilaterally by the client, with the server passively receiving heartbeat data packets to maintain the connection. When the client fails to send heartbeats on time due to network fluctuations, process abnormalities, or other reasons, the server often needs to wait a long time to detect the connection abnormality, making it difficult to promptly discover and handle abnormal connection states.

[0005] Second, the accuracy of anomaly detection is insufficient. Some existing technologies use a long-term connection validity timer to determine whether a connection is abnormal—when the timer value reaches a preset threshold and no heartbeat data packet is received, the connection is considered abnormal. However, this method does not fully consider the time difference between the heartbeat timestamp and the current moment, and is prone to misjudgment due to instantaneous network jitter, misidentifying a normal connection that could be recovered as an abnormal state and prematurely disconnecting it.

[0006] Third, the reconnection mechanism lacks proactive guidance from the server. In existing solutions, reconnection operations are usually performed by passive or active reconnection devices on the client side. After determining that the connection is abnormal, the server only passively waits for the client to reconnect and cannot provide the client with effective reconnection guidance information (such as reconnection address, reconnection strategy, etc.), resulting in low reconnection efficiency. Especially in server cluster deployment scenarios, the client may not be able to quickly connect to available service nodes.

[0007] Fourth, event push and connection state management are disconnected. In existing technologies, event data push and long-term connection state management are often independent of each other, lacking a unified connection state determination mechanism to coordinate push behavior. When the connection is in an abnormal state, the server may still attempt to push event data through that connection, resulting in data loss and resource waste.

[0008] In summary, how to provide a long connection status push method that can detect abnormal long connection states in a timely and accurate manner, actively guide the client to rebuild the connection when an abnormality occurs, and reliably push event data during normal connection periods is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0009] To achieve the objective of this invention, this application provides a long-connection status push method based on server-sent event heartbeat keep-alive, comprising: Step S1: In response to the client's heartbeat request, update the heartbeat timestamp of the long connection corresponding to the client; Step S2: Determine whether the long connection is in an abnormal state based on the time difference between the heartbeat timestamp and the current time; Step S3: When it is determined that the long connection is in an abnormal state, a reconnection instruction is sent to the client so that the client can rebuild the long connection based on the reconnection instruction; Step S4: During the period when the long connection is maintained in a normal state, push event data to the client through the long connection.

[0010] In some specific embodiments, the following steps are included before step S1: In response to the client's connection request, a long connection is established with the client, and the heartbeat timestamp is initialized.

[0011] In some specific embodiments, step S2 includes: Calculate the time difference between the current time and the heartbeat timestamp; when the time difference is greater than or equal to a preset heartbeat timeout threshold, determine that the long connection is in the abnormal state.

[0012] In some specific embodiments, step S3 includes: After determining that the long connection is in the abnormal state, the long connection is disconnected; a reconnection instruction carrying a reconnection address is sent to the client so that the client can re-initiate a connection request based on the reconnection address.

[0013] In some specific embodiments, after determining whether the long connection is in an abnormal state based on the time difference between the heartbeat timestamp and the current time, the method further includes: When the time difference is less than the heartbeat timeout threshold, the long connection is determined to be in the normal state, and the long connection is maintained.

[0014] In some specific embodiments, step S4 includes: Retrieve event data to be pushed; The event data is encapsulated into a data frame in the event format sent by the server. The data frame is sent to the client via the long connection.

[0015] In some specific embodiments, encapsulating the event data into a data frame in the event format sent by the server includes: Assign an event identifier to the event data; The event identifier and the event data are assembled into the data frame according to the server's event sending protocol.

[0016] In some specific embodiments, the following steps are included before step S1: Send heartbeat configuration parameters to the client, the heartbeat configuration parameters including the heartbeat sending interval and the heartbeat timeout threshold.

[0017] In some specific embodiments, it also includes: After the client rebuilds the long connection based on the reconnection instruction, the push of the event data is resumed through the rebuilt long connection.

[0018] To achieve the same inventive objective, this application also provides a long-connection status push system based on server-sent event heartbeat keep-alive, including a server and a client; The server is used to respond to the client's heartbeat request, update the heartbeat timestamp of the long connection corresponding to the client; determine whether the long connection is in an abnormal state based on the time difference between the heartbeat timestamp and the current time; when the long connection is determined to be in an abnormal state, send a reconnection instruction to the client; and push event data to the client through the long connection while the long connection is in a normal state. The client is used to send the heartbeat request to the server, and to receive the reconnection instruction and rebuild the long connection based on the reconnection instruction.

[0019] The beneficial effects of the above technical solution are as follows: This invention provides a long-connection status push method and system based on server-sent event heartbeat keep-alive. By responding to client heartbeat requests and updating the heartbeat timestamp in real time, the system dynamically determines whether the long connection is abnormal based on the time difference between the heartbeat timestamp and the current time. Compared to existing technologies that rely solely on timer timeouts, this method can detect connection anomalies more promptly and accurately, effectively avoiding misjudgments caused by network jitter. Furthermore, after determining a connection anomaly, the server proactively sends a reconnection instruction carrying a reconnection address to the client, guiding the client to quickly rebuild the connection, overcoming the inefficiency caused by the server passively waiting for reconnection in existing technologies. Moreover, this invention coordinates long-connection status management and event data push behavior based on a unified judgment mechanism, reliably pushing event data during normal connection periods and promptly disconnecting and triggering reconnection in case of anomalies, avoiding data loss and resource waste caused by continuing to push when the connection is unavailable. In addition, flexible adjustments to the heartbeat keep-alive strategy are achieved through configuration distribution, and event push is automatically restored after reconnection, further ensuring the continuity and reliability of the push service. The system architecture is clear and easy to deploy and expand on existing SSE communication architectures. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A flowchart illustrating a long-connection status push method based on server-sent event heartbeat keep-alive, as provided in an embodiment of the present invention; Figure 2 An overall architecture diagram of a long connection status push method based on server-sent event heartbeat keep-alive provided as an embodiment of the present invention; Figure 3 The flowchart below illustrates a long-connection status push method based on server-sent event heartbeat keep-alive, as provided in one embodiment of the present invention. Detailed Implementation

[0022] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0023] Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar symbols denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the invention, and should not be construed as limiting the invention.

[0024] Example 1 One embodiment of the present invention provides a long-connection status push method based on server-sent event heartbeat keep-alive, referring to... Figures 1-3 As shown, it includes: Step S1: In response to the client's heartbeat request, update the heartbeat timestamp of the long connection corresponding to the client; Step S2: Determine whether the long connection is in an abnormal state based on the time difference between the heartbeat timestamp and the current time; In one specific embodiment of the present invention, step S2 includes: Calculate the time difference between the current time and the heartbeat timestamp; when the time difference is greater than or equal to a preset heartbeat timeout threshold, determine that the long connection is in the abnormal state.

[0025] Step S3: When it is determined that the long connection is in an abnormal state, a reconnection instruction is sent to the client so that the client can rebuild the long connection based on the reconnection instruction; In a specific embodiment of the present invention, step S3 includes: After determining that the long connection is in the abnormal state, the long connection is disconnected; a reconnection instruction carrying a reconnection address is sent to the client so that the client can re-initiate a connection request based on the reconnection address.

[0026] Step S4: During the period when the long connection is maintained in a normal state, push event data to the client through the long connection.

[0027] In a specific embodiment of the present invention, step S4 includes: Retrieve event data to be pushed; The event data is encapsulated into a data frame in the event format sent by the server. The data frame is sent to the client via the long connection.

[0028] In one specific embodiment of the present invention, encapsulating the event data into a data frame in the event format sent by the server includes: Assign an event identifier to the event data; The event identifier and the event data are assembled into the data frame according to the server's event sending protocol.

[0029] In one specific embodiment of the present invention, the method further includes the following step before step S1: In response to the client's connection request, a long connection is established with the client, and the heartbeat timestamp is initialized.

[0030] In a specific embodiment of the present invention, after determining whether the long connection is in an abnormal state based on the time difference between the heartbeat timestamp and the current time, the method further includes: When the time difference is less than the heartbeat timeout threshold, the long connection is determined to be in the normal state, and the long connection is maintained.

[0031] In one specific embodiment of the present invention, the method further includes the following step before step S1: Send heartbeat configuration parameters to the client, the heartbeat configuration parameters including the heartbeat sending interval and the heartbeat timeout threshold.

[0032] In one specific embodiment of the present invention, it further includes: After the client rebuilds the long connection based on the reconnection instruction, the push of the event data is resumed through the rebuilt long connection.

[0033] One embodiment of the present invention provides a long-connection status push method based on server-sent event heartbeat keep-alive. This embodiment can be applied to scenarios such as real-time monitoring systems, message push platforms, and live video streaming services, where the server needs to continuously push event data to the client via a long-connection SSE (Server-Sent Events).

[0034] In one specific embodiment of the present invention, the method is executed by a server. A persistent HTTP connection (SSE) is pre-established between the server and the client. An SSE connection is a persistent HTTP connection through which the server can continuously send event data to the client without the client repeatedly initiating requests.

[0035] I. Connection Establishment and Initialization In this embodiment, when the client needs to receive event data pushed by the server, it first sends a connection request to the server. This connection request is an HTTP GET request, and the request header carries the Accept: text / event-stream field to indicate that the client expects to establish an SSE connection. After receiving and responding to the client's connection request, the server establishes a long-lived SSE connection with the client.

[0036] After establishing a persistent connection, the server assigns a unique connection ID to it for identification and management in subsequent processes. Simultaneously, the server initializes the heartbeat timestamp for this connection, setting it to the current value. The server also stores relevant information about the persistent connection (including connection ID, client address, heartbeat timestamp, connection status, etc.) in a connection management table for later connection status management and anomaly detection.

[0037] After establishing a persistent connection, the server sends heartbeat configuration parameters to the client. These parameters include the heartbeat interval and the heartbeat timeout. The heartbeat interval instructs the client on how often to send a heartbeat request to the server; the heartbeat timeout is used by the server to determine if the persistent connection is in an abnormal state. The heartbeat interval can be set to 30 seconds, and the heartbeat timeout can be set to 90 seconds (i.e., the heartbeat timeout is three times the heartbeat interval). The server sends these heartbeat configuration parameters to the client via an SSE persistent connection or a separate control channel.

[0038] II. Sending Client Heartbeat Requests After receiving the heartbeat configuration parameters from the server, the client starts a timer according to the heartbeat sending interval specified in the configuration parameters, periodically sending heartbeat requests to the server. This heartbeat request is an HTTP request, which can be a GET or POST request. The request carries the client's connection identifier so that the server can identify the long-lived connection corresponding to the heartbeat request. The client can send a heartbeat request to the server every 30 seconds.

[0039] 3. The server responds to the heartbeat request and updates the timestamp. After receiving a heartbeat request from a client, the server extracts the client's connection identifier from the request and uses this identifier to look up the corresponding long-lived connection and its heartbeat timestamp in the connection management table. Once the corresponding long-lived connection is found, the server updates the heartbeat timestamp of that connection to the current value. The server can also return a heartbeat response to the client to confirm that the heartbeat request has been successfully received and processed.

[0040] IV. Detection and Judgment of Abnormal Long-Term Connection States After updating the heartbeat timestamp, the server performs anomaly detection on long-lived connections either directly or according to a preset detection period. Specifically, the server obtains the current time value and calculates the time difference between the current time and the heartbeat timestamp. This time difference represents the time elapsed since the client last successfully sent a heartbeat request to the current time.

[0041] The server compares the calculated time difference with a preset heartbeat timeout threshold. When the time difference is greater than or equal to the heartbeat timeout threshold, the server determines that the long connection is in an abnormal state; when the time difference is less than the heartbeat timeout threshold, the server determines that the long connection is in a normal state. For example, when the heartbeat timeout threshold is set to 90 seconds, if the time difference between the current time and the heartbeat timestamp is greater than or equal to 90 seconds, it means that the client did not successfully send a heartbeat request within 90 seconds, and the long connection may be in an abnormal state due to network failure, client abnormality, or disconnection of intermediate devices; if the time difference is less than 90 seconds, it means that the long connection is still in a normal state.

[0042] In this embodiment, the server can perform abnormal state detection on long-lived connections using an active polling method. That is, the server starts a timed detection thread that iterates through all long-lived connections in the connection management table every preset detection period (e.g., 10 seconds), calculating the time difference for each connection and comparing it with a heartbeat timeout threshold. In another implementation, the server can also passively trigger abnormal state detection for the connection each time it receives a heartbeat request and updates the timestamp.

[0043] V. Reconnection Handling under Abnormal Conditions When the server determines that a persistent connection is in an abnormal state, it closes the connection and releases the associated resources (including network sockets, memory buffers, etc.). Simultaneously, the server sends a reconnection indication to the client. This reconnection indication can be sent via the callback address provided by the client when establishing the connection, or via other available communication channels.

[0044] Specifically, the reconnection instruction carries a reconnection address. This reconnection address can be a Uniform Resource Locator (URL) of a currently available service node in the server cluster, or it can be the address of a load balancer. After receiving the reconnection instruction, the client extracts the reconnection address from the instruction and re-initiates a connection request to the server based on the reconnection address, thereby rebuilding the SSE long connection.

[0045] After the client re-establishes the persistent connection based on the reconnection instruction, the server resumes the push of event data through the re-established persistent connection. Specifically, after re-establishing the connection, the server can retrieve the event data that the client failed to receive from the cache or database based on the client's connection identifier, and push this event data to the client through the re-established persistent connection.

[0046] VI. Heart rate maintenance and event notification under normal conditions When the server determines that the persistent connection is in a normal state, it maintains the connection and does not disconnect it. During the period when the persistent connection is in a normal state, the server pushes event data to the client through the persistent connection.

[0047] Specifically, the server acquires the event data to be pushed. This event data can be any data that needs to be pushed from the server to the client in real time, such as real-time monitoring data, system alarm information, live comment messages, or stock market data. The server encapsulates the event data into an SSE-formatted data frame. The SSE-formatted data frame conforms to the SSE protocol specification and includes fields such as `data:` (to carry the event data content), `event:` (to specify the event type), and `id:` (to specify the event identifier). In this embodiment, the server assigns an event identifier (Event ID) to the event data. This event identifier can be an incrementing sequence number or a unique identifier generated based on a timestamp. After assembling the event identifier and event data into a data frame according to the SSE protocol, the server sends the data frame to the client via a long-lived connection.

[0048] After receiving an SSE format data frame through a long connection, the client parses the data frame, extracts the event identifier and event data, and performs corresponding processing according to the event type.

[0049] In this embodiment, in order to further maintain the activity of the long connection, the server can also actively send an SSE comment line to the client during the long connection idle period (i.e. when there is no event data to push), for example, send a comment line starting with a colon (:heartbeat\n\n), to prevent intermediate network devices from actively disconnecting the connection due to connection idleness.

[0050] VII. Connection Restoration and Resumption of Disconnection When a client disconnects from the server due to network fluctuations, process restarts, or other reasons, it can include the last successfully received event identifier (Last-Event-ID) in the connection request when re-establishing an SSE long-lived connection with the server. Upon receiving the connection request with the Last-Event-ID, the server retrieves all event data following that identifier from the event store and pushes this event data to the client through the newly established long-lived connection, thus enabling resume transmission after a disconnection and ensuring no event data is lost.

[0051] This invention provides a long-connection status push method and system based on server-sent event heartbeat keep-alive. By responding to client heartbeat requests and updating the heartbeat timestamp in real time, the system dynamically determines whether the long connection is abnormal based on the time difference between the heartbeat timestamp and the current time. Compared with the existing technology that simply relies on timer timeout for determination, this method can detect connection anomalies more promptly and accurately, effectively avoiding misjudgments caused by instantaneous network jitter. At the same time, after determining that the connection is abnormal, the server actively sends a reconnection instruction carrying a reconnection address to the client, guiding the client to quickly rebuild the connection, overcoming the inefficiency caused by the server passively waiting for reconnection in the existing technology.

[0052] Example 2 One embodiment of the present invention provides a long-connection status push system based on server-sent event heartbeat keep-alive, including a server and a client; The server is used to respond to the client's heartbeat request, update the heartbeat timestamp of the long connection corresponding to the client; determine whether the long connection is in an abnormal state based on the time difference between the heartbeat timestamp and the current time; when the long connection is determined to be in an abnormal state, send a reconnection instruction to the client; and push event data to the client through the long connection while the long connection is in a normal state. The client is used to send the heartbeat request to the server, and to receive the reconnection instruction and rebuild the long connection based on the reconnection instruction.

[0053] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

[0054] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. The embodiments of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing terminal equipment to cause a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1The steps of the functions specified in one or more boxes. Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the invention. Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0055] The methods and apparatus provided by the present invention have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

[0056] In the description of this specification, references to terms such as "an embodiment," "some embodiments," "example," "specific example," or "a specific embodiment" or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0057] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for pushing the status of a long-lived connection based on server-sent event heartbeats, characterized in that, include: Step S1: In response to the client's heartbeat request, update the heartbeat timestamp of the long connection corresponding to the client; Step S2: Determine whether the long connection is in an abnormal state based on the time difference between the heartbeat timestamp and the current time; Step S3: When it is determined that the long connection is in an abnormal state, a reconnection instruction is sent to the client so that the client can rebuild the long connection based on the reconnection instruction; Step S4: During the period when the long connection is maintained in a normal state, push event data to the client through the long connection.

2. The long-connection status push method based on server-sent event heartbeat keep-alive according to claim 1, characterized in that, Step S1 is preceded by: In response to the client's connection request, a long connection is established with the client, and the heartbeat timestamp is initialized.

3. The long-connection status push method based on server-sent event heartbeat keep-alive according to claim 1, characterized in that, Step S2 includes: Calculate the time difference between the current time and the heartbeat timestamp; when the time difference is greater than or equal to a preset heartbeat timeout threshold, determine that the long connection is in the abnormal state.

4. The long-connection status push method based on server-sent event heartbeat keep-alive according to claim 3, characterized in that, Step S3 includes: After determining that the long connection is in the abnormal state, the long connection is disconnected; a reconnection instruction carrying a reconnection address is sent to the client so that the client can re-initiate a connection request based on the reconnection address.

5. The long-connection status push method based on server-sent event heartbeat keep-alive according to claim 3, characterized in that, After determining whether the long connection is in an abnormal state based on the time difference between the heartbeat timestamp and the current time, the method further includes: When the time difference is less than the heartbeat timeout threshold, the long connection is determined to be in the normal state, and the long connection is maintained.

6. The long-connection status push method based on server-sent event heartbeat keep-alive according to claim 1, characterized in that, Step S4 includes: Retrieve event data to be pushed; The event data is encapsulated into a data frame in the event format sent by the server. The data frame is sent to the client via the long connection.

7. The long-connection status push method based on server-sent event heartbeat keep-alive according to claim 6, characterized in that, The step of encapsulating the event data into a data frame in the event format sent by the server includes: Assign an event identifier to the event data; The event identifier and the event data are assembled into the data frame according to the server's event sending protocol.

8. The long-connection status push method based on server-sent event heartbeat keep-alive according to claim 1, characterized in that, Step S1 is preceded by: Send heartbeat configuration parameters to the client, the heartbeat configuration parameters including the heartbeat sending interval and the heartbeat timeout threshold.

9. The long-connection status push method based on server-sent event heartbeat keep-alive according to claim 1, characterized in that, Also includes: After the client rebuilds the long connection based on the reconnection instruction, the push of the event data is resumed through the rebuilt long connection.

10. A long-connection status push system based on server-sent event heartbeat keep-alive, characterized in that, Includes both server and client; The server is used to respond to the client's heartbeat request and update the heartbeat timestamp of the long connection corresponding to the client; Based on the time difference between the heartbeat timestamp and the current time, determine whether the long connection is in an abnormal state; When the long connection is determined to be in an abnormal state, a reconnection instruction is sent to the client; During the period when the long connection is maintained in a normal state, event data is pushed to the client through the long connection; The client is used to send the heartbeat request to the server, and to receive the reconnection instruction and rebuild the long connection based on the reconnection instruction.

Images