Message pushing method and device based on long connection, electronic equipment and medium

Abstract

The invention discloses a message pushing method and device based on long connection, electronic equipment and a medium in the technical field of computers, and the method comprises the steps: obtaining a pre-pushed message, and judging whether the pre-pushed message is a streaming message or not; and if the pre-pushed message is a streaming message, pushing the streaming message to a client based on a long connection, and pushing an instant message obtained in a streaming pushing process to the client after the streaming pushing process is ended. By adopting the method, complete pushing of the streaming message can be ensured, and the phenomenon of chaos cannot occur when the client displays the message.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a message push method, device, electronic device and medium based on a long connection. Background Art

[0002] With the development of web applications (Web applications), the network communication protocol WebSocket, as a protocol for full-duplex communication on a single TCP connection, has been widely used in interactive conversation scenarios. In interactive conversation scenarios, users can actively send messages through the client, and third-party systems can also push messages to users. Especially in the case of streaming message push with long text, the text is sent word by word, and users need to wait a relatively long time to see the complete content. In related technologies, during the streaming message push process, if other messages are pushed at the same time, the streaming message will be truncated or sent in batches, resulting in disordered message display. Users may not be able to see the complete information, affecting the user experience. Summary of the invention

[0003] Based on this, it is necessary to provide a message push method, device, electronic device and medium based on a long connection that can receive messages in an orderly manner and avoid disordered message display in response to the above technical problems.

[0004] A message push method based on a long connection, applied to a server, the method comprising:

[0005] Obtaining a pre-push message, and determining whether the pre-push message is a streaming message;

[0006] If the pre-push message is a streaming message, the streaming message is pushed to the client based on the persistent connection, and after the streaming push process is finished, the instant message obtained in the streaming push process is pushed to the client.

[0007] In the above solution, the instant message acquired in the streaming push process is pushed to the client, including:

[0008] The instant messages obtained in the streaming push process are sequentially stored in the waiting message queue;

[0009] All instant messages in the waiting message queue are pushed synchronously.

[0010] In the above solution, the determining whether the pre-push message is a streaming message includes:

[0011] Parsing the pre-push message to obtain a classification identifier corresponding to the pre-push message;

[0012] It is determined whether the classification identifier of the pre-push message is a streaming message.

[0013] In the above solution, pushing the streaming message to the client based on a long connection includes:

[0014] Parsing the streaming message, obtaining the streaming push start flag in the streaming message, and pushing the streaming message according to the streaming push start flag.

[0015] In the above solution, the method further includes:

[0016] When obtaining the streaming push start flag in the streaming message, marking the connection status of the client as streaming push.

[0017] In the above solution, storing the instant messages obtained during the pushing process of the streaming message into the waiting message queue in sequence includes:

[0018] Obtaining the instant message, and determining whether the server is in the process of streaming push according to the connection status;

[0019] If so, storing the instant message into the waiting message queue.

[0020] In the above solution, the method further includes:

[0021] If the pushing of the streaming message is completed, or no new streaming message is received within a set time period, clearing the streaming push flag in the connection status.

[0022] A message pushing device based on a long connection includes:

[0023] An obtaining module, configured to obtain a message to be pushed;

[0024] A judging module, configured to judge whether the message to be pushed is a streaming message;

[0025] A pushing module, configured to, if the message to be pushed is a streaming message, push the streaming message to the client based on a long connection, and after ending the streaming push process, push the instant messages obtained during the streaming push process to the client.

[0026] An electronic device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, the above message pushing method based on a long connection is implemented.

[0027] A computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the above message pushing method based on a long connection is implemented.

[0028] The above-mentioned long connection-based message push method, device, electronic device and medium, the server determines whether the obtained pre-push message is a streaming message. If so, the streaming message is pushed, and after the streaming push process ends, an instant message obtained during the streaming push process is pushed to the client, so that the client can receive the complete streaming message, ensuring that the client can receive the streaming message and other types of messages in an orderly manner and avoiding message confusion. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 It is a schematic flowchart of long connection-based message push in an embodiment;

[0030] Figure 2 It is a schematic flowchart of the server determining a streaming message in an embodiment;

[0031] Figure 3 It is a schematic flowchart of the server's processing of newly obtained instant messages in an embodiment;

[0032] Figure 4 It is a schematic flowchart of the server's processing of messages to be pushed in an embodiment;

[0033] Figure 5 It is a structural block diagram of long connection-based message push in an embodiment. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0034] In order to make the objectives, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0035] The implementation details of the technical solutions of the embodiments of the present application will be described in detail below.

[0036] In an embodiment, as Figure 1 shown, a long connection-based message push method is provided, and the method may include the following steps:

[0037] Step S101, obtain a pre-push message and determine whether the pre-push message is a streaming message.

[0038] The server can receive the pre-push message through a specified interface (such as WebSocket, etc.). The pre-push message refers to the message received by the server before the data is actually pushed. These messages may contain meta-information or content about the data to be pushed soon. By analyzing and processing the pre-push message, the server can decide how to construct the final push message to ensure that it meets the needs and expectations of the client.

[0039] The server analyzes and processes the obtained pre-push message to determine whether the pre-push message is a streaming message. Among them, a streaming message refers to data transmitted in the form of a continuous stream, which is usually used in real-time interaction scenarios, such as online chat, video conferencing, or games. The content of a streaming message is often continuous. During the process of pushing a streaming message, if it is interrupted, it may lead to the loss or confusion of information, affecting the integrity of the data, making it impossible for users to understand the context, and they may need to refocus their attention, resulting in an impact on information understanding. For example, in a video conference, if the push of a streaming message is interrupted, it may cause the view of a speaker to not be fully expressed. Therefore, in real-time interaction scenarios, it is necessary to ensure the complete push of streaming messages to enable users to obtain a smooth experience in real-time interaction scenarios.

[0040] In practical applications, the judgment of streaming messages can consider the following criteria:

[0041] (1) Message format. Streaming messages usually adopt specific formats, such as JSON, the data description language ProtocolBuffer, Avro, etc. Therefore, it can be judged whether the format of the pre-push message conforms to the standard of streaming messages.

[0042] (2) Message content. Streaming messages usually contain real-time data or time, rather than static data, and may also contain a timestamp field to indicate the time when the data is generated. Therefore, by analyzing the pre-push message, it can be judged whether it contains real-time data or events.

[0043] (3) Message transmission method. Streaming messages are usually sent through WebSocket or other real-time transmission protocols. If the pre-push message is received through these protocols, it may be a streaming message.

[0044] The server comprehensively judges whether the pre-push message is a streaming message through other factors such as message format, message content, and message transmission method.

[0045] In one embodiment, as Figure 2 shown, Figure 2 shows a schematic flowchart of the server judging a streaming message.

[0046] Step S201, parse the pre-push message to obtain the classification identifier corresponding to the pre-push message.

[0047] Step S202, judge whether the classification identifier of the pre-push message is a streaming message.

[0048] Here, the purpose of parsing the pre-push message is to extract key information from the received message, including the classification identifier. Among them, the server converts the received pre-push message into a processable format. For example, if the pre-push message is in JSON format, the server needs to parse it into the corresponding data structure (such as a dictionary or an object). Then, the server extracts the key information from the parsed message, including the classification identifier. The classification identifier is usually a field in the message, used to indicate the type or category of the message. In practical applications, the server can determine the field name of the classification identifier according to the predefined message format. For example, it may be "type" or other custom fields.

[0049] The server accesses the classification identifier field through the parsed data structure to obtain the corresponding field value, so as to judge whether the push message is a streaming message through the field value of the classification identifier. Exemplarily, when the classification identifier "type" is defined as "stream", it is regarded as a streaming message. Compare the extracted classification identifier with the predefined character value for the streaming message, and check whether the character value of the classification identifier matches the predefined character value. If it matches, it can be determined that the pre-push message is a streaming message; if it does not match, it can be determined that the message is not a streaming message.

[0050] In practical applications, the server can classify the obtained pre-push messages and assign a unique identifier (i.e., the classification identifier) to each type of message, so that the type of the pre-push message can be determined through the classification identifier.

[0051] It should be noted that for the pre-push message that does not belong to the streaming message, the server can push the pre-push message to the client through the long connection according to the usual push process.

[0052] In this embodiment, the server can effectively identify the message type, and thus adopt the corresponding push process to ensure that the server can correctly process different types of pre-push messages.

[0053] Step S102, if the pre-push message is a streaming message, push the streaming message to the client based on the long connection, and after the streaming push process ends, push the instant message obtained in the streaming push process to the client.

[0054] In the case where the pre-push message is a streaming message, it is necessary to perform corresponding processing on the pre-push message so that the server can push the pre-push message to the client completely.

[0055] The server can establish a long connection with the client through WebSocket. A long connection is a network communication method. In a long connection, after the client and the server establish a connection, the connection remains open, allowing multiple data exchanges, rather than establishing and closing the connection for each request. Only when it is no longer needed will the client or the server actively close the connection. During the period when the connection is maintained, the client can send requests to the server at any time, and the server can also actively push data to the client. This ability of two-way communication makes long connections very suitable for real-time interaction scenarios.

[0056] The server sends streaming messages to the client through the long connection, enabling the client to receive the streaming messages. Among them, during the server's streaming push process, if a new pre-push message is obtained, the server will not immediately push the newly obtained pre-push message to the client. Instead, it will wait until the current streaming message push ends, and after the server finishes the streaming push process, it will then push the newly obtained pre-push message during the streaming push process to the client. That is, during the process of pushing streaming messages, the server will not push other messages, thus ensuring that the client receives complete streaming messages and the client will not show a display disorder, so that users can better understand the message content.

[0057] It should be noted that the newly obtained pre-push messages during the streaming push process are mainly instant messages. This is because the push of streaming messages is usually a continuous process. The server will continuously send data streams within a certain period of time instead of sending them all at once. If the server receives a new streaming message to be pushed, it means that the current streaming push process has not ended. And instant messages refer to one-time messages generated and sent at a specific moment, usually used to convey updates of a certain time, status or notification, such as user notifications, status updates, time reminders, etc. Due to the real-time nature of instant messages, generally, when something happens or a condition is met at a certain time, an instant message is generated and then immediately pushed to the client by the server. However, during the streaming push process, if the generated instant messages are pushed in a timely manner, then the streaming messages and instant messages will be mixed and displayed on the client, making it difficult for users to understand the order and context of the messages and affecting the user experience. Based on this, in this embodiment, during the streaming push process, the generated instant messages are not immediately pushed to the client, but after the streaming push process ends, the instant messages are pushed to the client, thus avoiding the disordered display of instant messages and streaming messages on the client.

[0058] In one embodiment, during the process of pushing streaming messages, it is necessary to parse the streaming messages. The purpose of parsing the streaming messages is to extract the streaming push start marker in the streaming messages. The streaming push start marker is a specific identifier indicating the start of the streaming message push. The server parses the streaming messages according to a predefined streaming message format, and through the parsed data structure, checks whether the streaming push start marker field ("start" or other custom fields) is extracted from the streaming messages and obtains the corresponding field value. If it is detected that the character value of the streaming push start marker meets the expectation, it means that the streaming message push can start. Thus, the server uses an appropriate push mechanism according to the validity of the streaming push start marker to push the streaming messages to the server side.

[0059] In one embodiment, the connection state of the client refers to the current state of the network connection established between the client and the server. When the server detects the streaming push start marker contained in the streaming message, it indicates that the server decides to start pushing the streaming message. At this time, the connection state of the client is marked as streaming push, which means that this connection is used to receive real-time data streams. Among them, the identifier of the connection state can be a boolean value or other identifiers.

[0060] In practical applications, the server manages the push messages of multiple clients. When the server establishes a connection with a client, the server will obtain and record the information related to the connection with the client, such as the connection ID, client address, etc., and maintain a state management table according to this information to track the connection state of each client. Thus, when the server performs message pushing, it can confirm whether the client is in the streaming push state through the state management table to ensure the complete push of the streaming messages.

[0061] In one embodiment, as Figure 3 shown, Figure 3 shows the processing flow of the server for newly obtained instant messages, which may include:

[0062] Step S301, sequentially store the instant messages obtained during the push process of the streaming messages into the waiting message queue.

[0063] Step S302, synchronously push all the instant messages in the waiting message queue.

[0064] Here, the server maintains a waiting message queue for each client connection. This waiting message queue is used to temporarily store instant messages. In the streaming push process, the server may receive some instant messages that need to be pushed. To ensure the complete push of the streaming messages, these instant messages cannot be immediately pushed by the server, but are stored by the server in the waiting message queue for subsequent processing and pushing.

[0065] In practical applications, a suitable data structure (such as a queue, a list, etc.) is required for the waiting message queue to store the instant messages waiting to be pushed. The server adds the received instant messages to the waiting message queue in sequence. The enqueue operation of the queue can be used to add the instant message to the end of the queue.

[0066] After the server finishes the streaming push process, the server synchronously pushes all the instant messages in the waiting message queue. In practical applications, a loop structure can be used to sequentially retrieve messages from the waiting message queue and perform the push. Each time a message is retrieved from the queue, ensure that the message format meets the requirements of the client, and then use an appropriate push mechanism (such as WebSocket, etc.) to send the message to the client until all the instant messages are successfully pushed.

[0067] In practical applications, after the server finishes the streaming push process, it can first check whether the waiting message queue is empty. If the waiting message queue is empty, there is no need to perform the push; if there are messages in the waiting message queue, then it is necessary to push all the instant messages in the waiting message queue.

[0068] In this embodiment, the server can effectively manage the push of instant messages, ensuring the integrity of the streaming message push while ensuring that the client can also receive the required instant messages in a timely manner.

[0069] In one embodiment, the server maintains a status management table to track the connection status of each client. Each client's connection usually has a status identifier indicating whether the connection is in the streaming push state. The server determines whether the current connection between the server and the client is in the streaming push based on the client's connection status. If the connection status identifier is "in streaming push", it means that the server is performing streaming message push. At this time, the obtained instant messages need to be stored in the waiting message queue for subsequent push. If the server is not performing streaming message push, the obtained instant messages are directly pushed.

[0070] In this embodiment, the server can effectively manage the push of instant messages, ensuring that during the streaming message push process, while ensuring the complete push of the streaming message, it can also process instant messages in a timely manner to ensure the timeliness and accuracy of the messages.

[0071] In one embodiment, during the streaming message push process, the server indicates whether the streaming push process has ended by clearing the streaming push flag. Among them, there are two situations indicating that the streaming push process has ended, including:

[0072] (1) Completing the push of the streaming message means that the server has completely and successfully sent all the streaming messages to be pushed to the client.

[0073] (2) No new streaming messages are received. During the streaming push process, the server will continue to monitor whether there are new streaming messages arriving. The server defines a time window (such as 30 seconds). If no new streaming messages are received during this time, the streaming push is considered to have ended.

[0074] Once the streaming message push is confirmed to be completed, or no new streaming message is received within the set time, the server needs to clear the streaming push mark in the connection status, indicating that the connection is no longer in the streaming push state. Through this process, the server can effectively manage the streaming push state, ensure the reasonable use of system resources, and prepare for subsequent message push.

[0075] In actual applications, the server can manage the push of instant messages in the waiting message queue according to the connection status of the client. It is understandable that when the streaming push mark of the connection status is cleared, it indicates that the server has ended the streaming push process and can synchronously push the instant messages in the waiting message queue.

[0076] This application also provides an application embodiment, such as Figure 4 As shown, Figure 4 The figure shows a schematic diagram of the processing flow of the server side for the push message.

[0077] Step 1: Get the message to be pushed. When the server receives the message to be pushed, it first classifies the message and assigns a unique identifier to each message.

[0078] Step 2, determine whether the message to be pushed is a streaming message, if so, go to step 3 for processing; if not, go to step 4 for processing.

[0079] Step 3: Push message: When a streaming message needs to be pushed, the server marks the current connection state as streaming push.

[0080] Step 4, determine whether it is currently in streaming push, if so, go to step 5 for processing; if not, go to step 3 for processing and push the message to the client.

[0081] Step 5: Store the message in the waiting message queue. The server maintains a waiting message queue for each client connection to temporarily store instant messages. In streaming push, if the server receives an instant message, it will be placed in the corresponding waiting message queue in sequence.

[0082] Step 6, scheduled task detection. Here, it is used to detect whether the streaming push is ended at a scheduled time, and then return to step S4 for processing according to the obtained detection result, so that the server can synchronously push all instant messages in the waiting message queue when the streaming push ends, ensuring the order of the messages.

[0083] In the above embodiments, during the streaming message push process by the server, the client can ensure the complete push of messages during the reception of streaming messages. By pushing the instant messages obtained during the streaming push process after the streaming push ends, the server can avoid the phenomenon of disordered message display on the client side and improve the push effect of streaming messages.

[0084] In one embodiment, a message push device based on a long connection is provided. Referring to Figure 5 As shown, the long-connection-based push device 500 may include: an acquisition module 501, a judgment module 502, and a push module 503.

[0085] Among them, the acquisition module 501 is used to acquire pre-push messages;

[0086] The judgment module 502 is used to judge whether the pre-push message is a streaming message;

[0087] The push module 503 is used to, if the pre-push message is a streaming message, push the streaming message to the client based on the long connection, and after the streaming push process ends, push the instant messages obtained during the streaming push process to the client.

[0088] In one embodiment, the push module 503 is specifically used to sequentially store the instant messages obtained during the streaming push process into a waiting message queue; synchronously push all the instant messages in the waiting message queue.

[0089] In one embodiment, the judgment module 502 is specifically used to parse the pre-push message to obtain the classification identifier corresponding to the pre-push message; judge whether the classification identifier of the pre-push message is a streaming message.

[0090] In one embodiment, the push module 503 is specifically used to parse the streaming message to obtain the streaming push start flag in the streaming message, and push the streaming message according to the streaming push start flag.

[0091] In one embodiment, the push module 503 is specifically used to mark the connection state of the client as streaming push when obtaining the streaming push start flag in the streaming message.

[0092] In one embodiment, the push module 503 is specifically used to obtain the instant message, and determine whether the server is in the streaming push according to the connection state; if so, store the instant message into the waiting message queue.

[0093] In one embodiment, the push module 503 is specifically configured to clear the streaming push flag in the connection status if the streaming message is pushed successfully, or if no new streaming message is received within a set duration.

[0094] For the specific limitations of the long - connection - based push device 500, reference can be made to the limitations of the long - connection - based push method described above, which will not be elaborated here. Each module in the above - mentioned long - connection - based push device 500 can be implemented in whole or in part by software, hardware, or a combination thereof. The above - mentioned modules can be embedded in the processor of the computer device in hardware form or be independent of it, or be stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to the above - mentioned modules.

[0095] In one embodiment, an electronic device is provided, which includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, a long - connection - based push method is implemented.

[0096] In one embodiment, a computer storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, a long - connection - based push method is implemented.

[0097] It should be noted that the logic and / or steps represented in the flowchart or described in other ways herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer - readable medium for use by an instruction - execution system, apparatus, or device (such as a computer - based system, a system including a processor, or other systems that can fetch and execute instructions from the instruction - execution system, apparatus, or device), or in combination with these instruction - execution systems, apparatus, or devices. For the purposes of this specification, a "computer - readable medium" can be any device that can contain, store, communicate, propagate, or transport a program for use by or in connection with an instruction - execution system, apparatus, or device. More specific examples (non - exhaustive list) of the computer - readable medium include the following: an electrical connection portion with one or more wirings (electronic device), a portable computer diskette (magnetic device), a random access memory (RAM), a read - only memory (ROM), an erasable programmable read - only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read - only memory (CDROM). Additionally, the computer - readable medium can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other media, then editing, interpreting, or processing it in other suitable ways as necessary, and then storing it in the computer memory.

[0098] It should be understood that various parts of the present invention can be implemented by hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, any one of the following techniques known in the art or a combination thereof can be used: discrete logic circuits having logic gate circuits for implementing logical functions on data signals, application specific integrated circuits having appropriate combinational logic gate circuits, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

[0099] In the description of this specification, the description referring to terms such as "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0100] In addition, the terms "first" and "second" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" can explicitly or implicitly include at least one of these features. In the description of the present invention, the meaning of "a plurality" is at least two, such as two, three, etc., unless otherwise specifically and clearly defined.

[0101] Although the embodiments of the present invention have been shown and described above, it can be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those of ordinary skill in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present invention.

Claims

1. A message push method based on long connection, characterized in that Applied to a server, the method includes: Obtain a pre-push message and determine whether the pre-push message is a streaming message; If the pre-push message is a streaming message, push the streaming message to the client based on a long connection, and after the streaming push process ends, push the instant message obtained during the streaming push process to the client.

2. The message push method based on long connection according to claim 1, wherein The pushing the instant message obtained during the streaming push process to the client includes: Sequentially store the instant messages obtained during the streaming push process into a waiting message queue; Synchronously push all the instant messages in the waiting message queue.

3. The message push method based on long connection according to claim 1, wherein The determining whether the pre-push message is a streaming message includes: Parse the pre-push message to obtain the classification identifier corresponding to the pre-push message; Determine whether the classification identifier of the pre-push message is a streaming message.

4. The message push method based on long connection according to claim 2, wherein The pushing the streaming message to the client based on a long connection includes: Parse the streaming message to obtain the streaming push start flag in the streaming message, and push the streaming message according to the streaming push start flag.

5. The method for message push based on long connection according to claim 4, wherein The method further includes: When obtaining the streaming push start flag in the streaming message, mark the connection status of the client as streaming push.

6. The method for message push based on long connection according to claim 5, wherein The sequentially storing the instant messages obtained during the pushing process of the streaming message into a waiting message queue includes: Obtain the instant message and determine whether the server is in the process of streaming push according to the connection status; If so, store the instant message into the waiting message queue.

7. The message push method based on long connection according to claim 5, wherein The method further includes: If the pushing of the streaming message is completed, or no new streaming message is received within a set duration, clear the streaming push flag in the connection status.

8. A message push device based on long connection, characterized in that, It includes: An obtaining module for obtaining a pre-push message; A judging module for judging whether the pre-push message is a streaming message; A pushing module for, if the pre-push message is a streaming message, pushing the streaming message to the client based on a long connection, and after the streaming push process ends, pushing the instant message obtained during the streaming push process to the client.

9. An electronic device, comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the long-connection-based message pushing method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the long-connection-based message pushing method according to any one of claims 1 to 7.

Images