Long connection communication method, system, client and server

Abstract

The application relates to a long connection communication method, system, client and server, wherein the long connection communication method comprises the following steps: when a user-triggered long connection establishment instruction is monitored, a client generates a query request corresponding to a user according to a client identifier of the client and a user identifier of the user; the query request is used to request to query whether the user is legal; further, the client sends the query request to a server, so that the server determines whether the user is legal according to the query request, obtains a first query result, and returns the first query result to the client; subsequently, the client receives the first query result, and determines whether to initiate a long connection communication establishment request to the server according to the first query result. Through the application, the operation efficiency of a communication link is effectively improved.

Description

Technical Field

[0001] This application relates to the field of long-connection communication technology, and in particular to a long-connection communication method, system, client, and server. Background Technology

[0002] In scenarios where clients and servers communicate via long-lived connections (such as WebSocket), such as instant messaging, real-time data push, and collaborative editing, a persistent bidirectional communication channel can be established between the client and server with a single handshake. This allows both the client to send data to the server and the server to proactively push data to the client. To ensure communication security, it is usually necessary to verify the legitimacy of the user initiating the request during the connection establishment phase.

[0003] Currently, clients typically initiate connection establishment requests directly to the server, which then verifies the corresponding user upon receiving the request. However, this verification method incurs unnecessary connection establishment overhead and resource consumption, resulting in low efficiency of the communication link.

[0004] There is currently no effective solution to the problem of low operating efficiency of communication links in related technologies. Summary of the Invention

[0005] This embodiment provides a long-connection communication method, system, client, and server, aiming to improve the operating efficiency of the communication link.

[0006] Firstly, this embodiment provides a long-connection communication method, which is applied to a client; the long-connection communication method includes:

[0007] When a long connection establishment command triggered by a user is detected, a query request corresponding to the user is generated based on the client's client identifier and the user's user identifier; wherein, the query request is used to query whether the user is legitimate;

[0008] The query request is sent to the server, so that the server determines whether the user is legitimate based on the query request, obtains a first query result, and returns the first query result to the client;

[0009] Receive the first query result and determine whether to initiate a long connection communication establishment request to the server based on the first query result.

[0010] Secondly, this embodiment provides a long-connection communication method, which is applied to a server; the long-connection communication method includes:

[0011] Upon receiving a query request from a client, the system determines whether the user corresponding to the query request is legitimate based on the query request, and obtains a first query result. The query request is generated by the client based on the client's client identifier and the user's user identifier when the client detects a long connection establishment instruction triggered by the user, and then sends it to the server.

[0012] The first query result is sent to the client so that the client can determine whether to initiate a long connection communication establishment request to the server based on the first query result.

[0013] Thirdly, this embodiment provides a long-connection communication method, which is applied to a long-connection communication system; the long-connection communication system includes a client and a server; the long-connection communication method includes:

[0014] When the client detects a long connection establishment instruction triggered by the user, it generates a query request corresponding to the user based on the client's client identifier and the user's user identifier; wherein, the query request is used to query whether the user is legitimate;

[0015] The client sends the query request to the server;

[0016] The server determines whether the user is legitimate based on the query request, obtains a first query result, and returns the first query result to the client;

[0017] The client receives the first query result and determines whether to initiate a long connection communication establishment request to the server based on the first query result.

[0018] Fourthly, this embodiment provides a communication system, which includes a client and a server; wherein,

[0019] The client is configured to generate a query request corresponding to the user based on the client identifier of the client and the user identifier of the user when a long connection establishment instruction triggered by the user is detected; wherein, the query request is used to query whether the user is legitimate;

[0020] The client is also used to send the query request to the server;

[0021] The server is configured to determine whether the user is legitimate based on the query request, obtain a first query result, and return the first query result to the client.

[0022] The client is also configured to receive the first query result and determine whether to initiate a long connection communication establishment request to the server based on the first query result.

[0023] Fifthly, this embodiment provides a client, the client comprising:

[0024] The generation module is used to generate a query request corresponding to the user based on the client identifier of the client and the user identifier of the user when a long connection establishment instruction triggered by the user is detected; wherein, the query request is used to query whether the user is legitimate;

[0025] The query module is used to send the query request to the server, so that the server determines whether the user is legitimate based on the query request, obtains a first query result, and returns the first query result to the client;

[0026] The judgment module is used to receive the first query result and determine whether to initiate a long connection communication establishment request to the server based on the first query result.

[0027] Sixthly, this embodiment provides a server, the server comprising:

[0028] The verification module is used to determine whether the user corresponding to the query request is legitimate based on the query request when a query request is received from the client, and to obtain a first query result; wherein, the query request is generated by the client based on the client's client identifier and the user's user identifier when the client detects the long connection establishment instruction triggered by the user and sends it to the server;

[0029] The sending module is used to send the first query result to the client, so that the client can determine whether to initiate a long connection communication establishment request to the server based on the first query result.

[0030] Compared with related technologies, this embodiment provides a long-connection communication method, system, client, and server. When the client detects a long-connection establishment command triggered by a user, it generates a query request corresponding to the user based on the client's client identifier and the user's user identifier. The query request is used to query whether the user is legitimate. Further, the client sends the query request to the server, so that the server determines whether the user is legitimate based on the query request, obtains a first query result, and returns the first query result to the client. Subsequently, the client receives the first query result and determines whether to initiate a long-connection communication establishment request to the server based on the first query result.

[0031] In this way, by performing a user legitimacy check before the client initiates a long connection, and only sending long connection establishment requests to legitimate users, illegal connection requests can be intercepted in advance, and the server can avoid generating invalid connection creation actions, thereby reducing unnecessary connection overhead and resource consumption, and effectively improving the operating efficiency of the communication link.

[0032] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0033] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0034] Figure 1 This is a flowchart of an embodiment of the long-connection communication method provided in this application;

[0035] Figure 2 This is a flowchart of Embodiment 2 of the long-connection communication method provided in this application;

[0036] Figure 3 This is a flowchart of Embodiment 3 of the long-connection communication method provided in this application;

[0037] Figure 4 This is a flowchart of Embodiment 4 of the long-connection communication method provided in this application;

[0038] Figure 5 This is a flowchart of Embodiment 5 of the long-connection communication method provided in this application;

[0039] Figure 6 This is a flowchart of Embodiment Six of the long-connection communication method provided in this application;

[0040] Figure 7 This is a flowchart of Embodiment Seven of the Long Connection Communication Method provided in this application;

[0041] Figure 8 This is a flowchart of Embodiment 8 of the long-connection communication method provided in this application;

[0042] Figure 9 This is a flowchart of Embodiment Nine of the long-connection communication method provided in this application;

[0043] Figure 10 This is a structural block diagram of the long-connection communication system provided in this application;

[0044] Figure 11 This is a structural block diagram of the client provided in this application;

[0045] Figure 12 This is a structural block diagram of the server provided in this application. Detailed Implementation

[0046] To better understand the purpose, technical solution, and advantages of this application, the application is described and illustrated below in conjunction with the accompanying drawings and embodiments.

[0047] Unless otherwise defined, the technical or scientific terms used in this application shall have the general meaning understood by one of ordinary skill in the art to which this application pertains. Words such as “a,” “an,” “an,” “the,” “the,” and “these” used in this application do not indicate quantitative limitation and may be singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that comprises a series of steps or modules (units) is not limited to the listed steps or modules (units) but may include steps or modules (units) not listed, or may include other steps or modules (units) inherent to these processes, methods, products, or devices. Words such as “connected,” “linked,” and “coupled” used in this application are not limited to physical or mechanical connections but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. Normally, the character " / " indicates that the objects before and after it are in an "or" relationship. The terms "first," "second," "third," etc., used in this application are merely to distinguish similar objects and do not represent a specific order of objects.

[0048] The following specific embodiments are given to illustrate the technical solution of this application in detail.

[0049] Figure 1 This is a flowchart illustrating an embodiment of the long-connection communication method provided in this application, which is applied to a client. Please refer to... Figure 1 The method provided in this embodiment may include the following steps:

[0050] Step S101: When a long connection establishment instruction triggered by a user is detected, a query request corresponding to the user is generated based on the client's client identifier and the user's user identifier; wherein, the query request is used to request whether the user is legitimate.

[0051] It should be noted that the long connection establishment command triggered by the user on the client side instructs the client to initiate the user legitimacy verification process before establishing a long connection. This long connection establishment command can originate from various scenarios, such as when a user logs into an instant messaging tool or enables a real-time data push function.

[0052] Specifically, when the client detects a long connection establishment command triggered by a user, it obtains the client's client identifier and the user's user identifier. The client identifier is used to distinguish different client devices and is typically a client machine code. The user identifier is used to uniquely identify the user, such as a unique user ID assigned by the system or a user login account.

[0053] Furthermore, the client combines and encapsulates the client's identifier and the user's identifier according to a preset protocol format to generate a query request for determining whether the user is legitimate.

[0054] Step S102: Send the query request to the server so that the server can determine whether the user is legitimate based on the query request, obtain the first query result, and return the first query result to the client.

[0055] In practice, after generating a query request, the client can start a pre-created first thread, which then calls the query interface provided by the server to send the query request to the server.

[0056] Furthermore, the server determines whether the user is legitimate based on the query request, obtains the first query result, and returns the first query result to the client. This first query result is used to characterize whether the user is legitimate. The specific implementation of determining user legitimacy based on the query request will be explained in detail below when discussing server-side communication methods.

[0057] Step S103: Receive the first query result and determine whether to initiate a long connection communication establishment request to the server based on the first query result.

[0058] Specifically, the client determines user legitimacy by parsing the first query result. If the user is deemed legitimate, the client executes the long-connection establishment process, which involves the client starting a pre-created second thread and initiating a long-connection establishment request to the server according to the long-connection protocol. If the user is deemed illegitimate, the client terminates the long-connection establishment process and no longer initiates a long-connection establishment request to the server.

[0059] Optionally, the client is configured with a retry mechanism to handle query failures caused by network jitter or abnormal server responses. Specifically, after sending a query request, if the client does not receive the first query result within a preset time period, or if the received response data has format errors or parsing failures, the retry mechanism is initiated. This involves re-executing steps S101 to S102 until a parsable first query result is successfully received or the maximum number of retries is reached. It should be noted that if a parsable first query result is not received after reaching the maximum number of retries, the client can terminate the long-connection communication establishment process.

[0060] The long-connection communication method provided in this embodiment involves the client generating a query request corresponding to the user based on the client's client identifier and the user's user identifier when it detects a long-connection establishment command triggered by the user. This query request is used to check whether the user is legitimate. Further, the client sends the query request to the server, allowing the server to determine the user's legitimacy based on the query request, obtain a first query result, and return the first query result to the client. Subsequently, the client receives the first query result and determines whether to initiate a long-connection communication establishment request to the server based on the first query result. In this way, by pre-completing the user legitimacy query before the client initiates a long connection, and only initiating long-connection establishment requests for legitimate users, illegal connection requests can be intercepted in advance, and invalid connection creation actions by the server can be avoided. This reduces unnecessary connection overhead and resource consumption, effectively improving the operating efficiency of the communication link.

[0061] Figure 2 This is a flowchart of Embodiment 2 of the long-connection communication method provided in this application. Please refer to... Figure 2 Based on the above embodiments, determining whether to initiate a long connection communication establishment request to the server according to the first query result includes:

[0062] Step S201: Extract the target field used to characterize whether the user is legitimate from the first query result.

[0063] Specifically, after receiving the first query result returned by the server, the client extracts the target field used to characterize whether the user is legitimate from the first query result.

[0064] It should be noted that the first query result is typically returned in a structured data format (e.g., JSON or a custom protocol message format), and includes predefined target fields. The values ​​of these target fields reflect whether the user is legitimate. For example, `true` indicates a legitimate user, and `false` indicates an illegitimate user. This application does not limit the specific value format of the target fields.

[0065] Step S202: When the target field indicates that the user is legitimate, a long connection communication establishment request is initiated to the server.

[0066] In this step, when the value of the target field indicates that the user is legitimate, it means that the current user's identity is valid and the account status is normal. In this case, the client will execute the long-connection communication establishment process. Specifically, the client can initiate a long-connection communication establishment request to the server through a pre-created second thread.

[0067] Step S203: When the target field indicates that the user is illegitimate, the operation of initiating a long connection communication establishment request to the server is abandoned, and a first reminder message is output; wherein, the first reminder message is used to prompt the user that the user is illegitimate.

[0068] In this step, when the value of the target field indicates that the user is illegitimate, the client abandons the operation of initiating a long-lived connection communication request to the server. Furthermore, the client can generate a first alert message based on the specific reason for the user's illegitimacy carried in the first query result (e.g., account frozen, account expired, etc.). This alert message is used to notify the user of the illegitimacy and can display the specific reason for the illegitimacy.

[0069] The method provided in this embodiment queries the server in advance to check whether the user is legitimate before the client initiates a long connection communication establishment request, and determines whether to actually initiate a long connection communication establishment request to the server based on the query result. This effectively avoids invalid connections from occupying server resources, and outputs corresponding prompts when the connection is illegitimate, thereby improving system security.

[0070] Figure 3 This is a flowchart of Embodiment 3 of the long-connection communication method provided in this application. Please refer to... Figure 3 Based on the above embodiments, after receiving the first query result, the process includes:

[0071] Step S301: Cache the first query result in the first database.

[0072] In this embodiment, after receiving the first query result returned by the server, the client stores the value of the target field used to characterize whether the user is legitimate (i.e., the user's legitimacy status information) extracted from the result into a preset first database. Specifically, the first database can be deployed on a separate node for access by both the client and the server. Furthermore, the first database can be selected from databases such as Redis, depending on the actual application requirements; no specific limitation is made here.

[0073] Optionally, when storing user legitimacy status information in the first database, it can be stored in key-value pair format. For example, the user identifier can be used as the key name, and the value of the target field can be used as the key value.

[0074] It should be noted that this embodiment does not specifically limit the data format stored in the first database, and the storage format can be flexibly selected according to actual business needs. In specific implementation, the value of the target field (e.g., true / false) can be stored directly, or the data mapped to the value can be stored (e.g., mapping true to 1 and false to 0).

[0075] The method provided in this embodiment caches the first query result in a first database, allowing the client to retrieve previously stored user legitimacy information from the cache when it needs to re-verify user legitimacy later. This effectively reduces redundant interactions between the client and the server, thereby reducing the query load on the server and backend system, while significantly improving client response speed.

[0076] Figure 4 The flowchart is for Embodiment 4 of the long-connection communication method provided in this application. Please refer to... Figure 4 Based on the above embodiments, before generating the query request corresponding to the user according to the client's client identifier and the user's user identifier, the long connection communication method further includes:

[0077] Step S401: Check if the target query result corresponding to the user exists in the first database.

[0078] In this embodiment, when the client detects a long connection establishment command triggered by the user, it pre-checks the first database to see if a target query result corresponding to the user exists. It should be noted that this target query result is the legitimacy status information cached in the first database in step S301, used to characterize whether the user is legitimate.

[0079] In practice, the client can use the user identifier as the retrieval basis to initiate a query operation to the first database. If the first database contains the legitimacy status information corresponding to the user identifier, then the legitimacy status information corresponding to the user identifier will be returned as the target query result.

[0080] Step S402: When the target query result corresponding to the user exists in the first database, and the target query result indicates that the user is legitimate, a long connection communication establishment request is initiated to the server.

[0081] Specifically, when the target query result corresponding to the user is successfully found in the first database, the client further determines whether the target query result indicates that the user is legitimate. If the target query result indicates that the user is legitimate, it means that the user's legitimacy has been verified. At this point, the client does not need to send another query request to the server and can directly send a long-lived connection communication establishment request to the server.

[0082] Step S403: When there is no target query result corresponding to the user in the first database, or when there is a target query result corresponding to the user in the first database and the target query result indicates that the user is invalid, a query request is generated based on the client's client identifier and the user's user identifier.

[0083] Specifically, if the target query result for a user does not exist in the first database, it indicates that the user has not yet undergone legitimacy verification, or that the previously cached user entry has expired and been cleared. Furthermore, since a user's status may change within the cache's validity period, if the target query result exists in the first database and indicates that the user is illegitimate, a new legitimacy query can be initiated with the server.

[0084] In both of the above scenarios, a query request is generated based on the client's client identifier and the user's user identifier, and then the query request is sent to the server.

[0085] The method provided in this embodiment prioritizes searching the cached user legitimacy status information in the first database before generating a query request. When the cache is hit and the result indicates the user is legitimate, the client can directly initiate a long-lived connection establishment request, avoiding redundant interaction with the server and reducing network overhead and server load. Furthermore, when the cache is missed or the cached result is invalid, the client initiates a real-time query process to ensure the latest user status is obtained, thus balancing communication efficiency with the accuracy of user legitimacy verification results.

[0086] Figure 5 The flowchart is for Embodiment 5 of the long-connection communication method provided in this application. Please refer to... Figure 5 Based on the above embodiments, after successfully establishing a long-connection communication with the server, the long-connection communication method further includes:

[0087] Step S501: Upon receiving each streaming message sent by the server in response to a specified business request, the streaming message is validated to obtain a validation result for each streaming message; wherein, the validation result is used to characterize whether each streaming message is valid.

[0088] Specifically, after the client successfully establishes a long-term connection with the server, when the server responds to a specific business request (e.g., real-time data push, file chunked transfer, etc.) and sends a streaming message to the client, the client verifies each streaming message it receives.

[0089] Specifically, the client verifies each streaming message according to preset verification rules (e.g., message format verification, digital signature verification, message sequence number continuity check, sensitive word check, etc.) and obtains the corresponding verification result. The verification result is used to indicate whether the streaming message is valid.

[0090] It should be noted that the above verification rules can be flexibly configured according to specific business scenarios and security requirements. The verification rules in this step may include a combination of one or more verification methods.

[0091] Step S502: Return the verification result to the server so that the server can determine whether to send subsequent streaming messages under the specified business request to the client based on the verification result; wherein, the subsequent streaming messages include all unsent streaming messages in all streaming messages corresponding to the specified business request.

[0092] Specifically, the client returns the verification result for each streaming message to the server in real time. After receiving the verification result, the server determines whether to continue sending subsequent streaming messages for the current specified business request to the client based on the verification result.

[0093] If the verification result indicates that the current streaming message is valid, the server continues to send subsequent streaming messages for the currently specified service request to the client. If the verification result indicates that the current streaming message is invalid, the server may terminate the sending of subsequent streaming messages.

[0094] It should be noted that subsequent streaming messages include all unsent streaming messages corresponding to the specified service request. For example, if a specified service request corresponds to 10 streaming messages to be sent, the server will send the 10 streaming messages to the client in sequence. After the client successfully verifies the first 3 messages and returns a valid result, the 4th to 10th messages that have not yet been sent are the subsequent streaming messages.

[0095] It should be understood that during the process of the server sending subsequent streaming messages to the client, the client will perform the above verification process for each received streaming message. That is, every time the server sends a streaming message to the client, it needs to receive the verification result returned by the client and determine whether to continue sending streaming messages based on the verification result.

[0096] The method provided in this embodiment performs real-time verification on each streaming message during long-connection communication and provides feedback on the verification result. This allows the server to dynamically determine whether to continue sending subsequent messages based on the verification result. When verification fails, subsequent message transmission is terminated in a timely manner, thereby avoiding invalid data from consuming network bandwidth and client processing resources. It also effectively prevents the continuous transmission of illegal or tampered messages, improving the reliability, security, and transmission efficiency of streaming transmission.

[0097] Figure 6 This is a flowchart of Embodiment Six of the long-connection communication method provided in this application. This long-connection communication method is applied to a server. Please refer to... Figure 6 The method provided in this embodiment may include the following steps:

[0098] Step S601: Upon receiving a query request from the client, determine whether the user corresponding to the query request is legitimate based on the query request, and obtain the first query result; wherein, the query request is generated by the client based on the client's client identifier and the user's user identifier when the client detects the long connection establishment instruction triggered by the user and sends it to the server.

[0099] In this step, after receiving a query request, the server determines whether the user corresponding to the query request is legitimate based on preset verification logic. This verification process may include verifying the legitimacy of the client device and the status of the user account.

[0100] For example, in one embodiment, determining whether the user corresponding to the query request is legitimate based on the query request includes: extracting the client identifier from the query request, and verifying the legitimacy of the client based on the client identifier to obtain a first verification result; determining that the user is illegitimate when the first verification result indicates that the client is illegitimate; extracting the user identifier from the query request when the first verification result indicates that the client is legitimate; verifying the legitimacy of the user based on the user identifier to obtain a second verification result, and determining whether the user is legitimate based on the second verification result.

[0101] It should be noted that the server pre-extracts the client identifier from the query request and performs a validity check on the client based on the client identifier to obtain the first verification result. If the first verification result indicates that the client is illegitimate (e.g., the current client is blacklisted, disabled, or exceeds the authorized scope), then the user is determined to be illegitimate. If the first verification result indicates that the client is legitimate, then the user identifier is extracted from the query request.

[0102] In practice, client legitimacy verification includes checking whether the current client is blacklisted, disabled, or exceeds the authorized scope. For example, if the current client is detected to be blacklisted, the first verification result is that the client is illegitimate; otherwise, the first verification result is that the client is legitimate.

[0103] Furthermore, the legitimacy of the user is verified based on the user identifier, resulting in a second verification result. If the second verification result indicates that the user is illegitimate (e.g., the user account is frozen, expired, or has other abnormalities), then the user is determined to be illegitimate. Conversely, if the second verification result indicates that the user is legitimate, then the user is determined to be legitimate.

[0104] In practice, user legitimacy verification includes checking whether the user account has been frozen or is within its validity period. For example, if a frozen user account is detected, the second verification result is that the user is illegitimate; otherwise, the first verification result is that the user is legitimate.

[0105] It should be understood that in practical applications, the verification methods for clients and users can be flexibly configured according to specific business scenarios and security requirements. The verification logic provided in this application embodiment is only for illustrative purposes and does not constitute a specific limitation on the verification method.

[0106] Step S602: The first query result is sent to the client so that the client can determine whether to initiate a long connection communication establishment request to the server based on the first query result.

[0107] In this step, the server sends the first query result to the client. After receiving the first query result, the client determines whether to initiate a long connection communication establishment request to the server based on the first query result.

[0108] In practice, the client determines user legitimacy by parsing the first query result. If the user is deemed legitimate, the client executes the long-connection establishment process, which involves starting a pre-created second thread and initiating a long-connection establishment request to the server according to the long-connection protocol. If the user is deemed illegitimate, the client terminates the long-connection establishment process and no longer initiates long-connection establishment requests to the server.

[0109] The long-connection communication method provided in this embodiment, upon receiving a query request from a client, determines whether the user corresponding to the query request is legitimate based on the query request, thus obtaining a first query result. The query request is generated by the client based on its client identifier and the user identifier when it detects a long-connection establishment instruction triggered by a user, and is then sent to the server. Subsequently, the first query result is sent to the client so that the client can determine whether to initiate a long-connection communication establishment request to the server based on the first query result. In this way, by performing a user legitimacy query before the client initiates a long connection, it ensures that only legitimate users can trigger the subsequent long-connection establishment process, thereby intercepting illegal connection requests in advance, preventing the server from generating invalid connection creation actions, reducing unnecessary connection overhead and resource consumption, and effectively improving the operating efficiency of the communication link.

[0110] Figure 7 The flowchart is for Embodiment Seven of the long-connection communication method provided in this application. Please refer to... Figure 7 Based on the above embodiments, after successfully establishing a long-connection communication with the client, the long-connection communication method further includes:

[0111] Step S701: In response to the specified service request sent by the client, after sequentially sending each streaming message corresponding to the specified service request to the client, receive the verification result of each streaming message returned by the client; wherein, the verification result is used to characterize whether each streaming message is valid.

[0112] Specifically, after receiving a specified business request (such as real-time data push, file chunked transfer, etc.) from the client, the server sends the corresponding streaming messages to the client one by one in sequence.

[0113] It should be noted that after the server sends each streaming message to the client, it receives a verification result for that streaming message from the client. This verification result is generated by the client based on the received streaming message and is used to indicate whether the streaming message is valid.

[0114] Step S702: Determine whether to continue sending subsequent streaming messages under the specified service request to the client based on the verification result; wherein, the subsequent streaming messages include all unsent streaming messages in all streaming messages corresponding to the specified service request.

[0115] In this step, if the verification result indicates that the streaming message is valid, subsequent streaming messages under the specified service request will continue to be sent to the client. If the verification result indicates that the streaming message is invalid, subsequent streaming messages under the specified service request will stop being sent to the client.

[0116] In practice, after receiving the verification result corresponding to the first streaming message returned by the client, the server can store the verification result in a pre-defined second database (e.g., Redis). The second database can specify the request identifier of the business request as the key name and the verification result as the key value for storage (e.g., true indicates valid and false indicates invalid).

[0117] For each streaming message following the first one under this specified service request, the server pre-searches the key-value pair corresponding to the specified service request in the second database before sending each streaming message to the client for verification. If the key-value pair corresponding to the specified service request is valid in the second database, the server can send the streaming message to the client for verification. Upon receiving the verification result returned by the client for the streaming message, the server updates the key-value pair corresponding to the specified service request to the verification result. If the key-value pair corresponding to the specified service request is invalid, the server terminates the sending of subsequent streaming messages under this specified service request.

[0118] In another possible implementation, the server responds to a specified business request sent by the client by initiating a pre-created third thread. This third thread calls a validation interface provided by the client to sequentially send each streaming message corresponding to the specified business request to the client, and then waits to receive the validation result for each streaming message from the client. The validation interface verifies the validity of the streaming message. Subsequently, if the received validation result indicates that the current streaming message is valid, the server can initiate a pre-created fourth thread to send the streaming message to the client, thus formally pushing the streaming message to the client's business processing layer. Then, the third thread can continue sending the next streaming message for validation. If the validation result indicates that the current streaming message is invalid, the sending of subsequent streaming messages under that specified business request is terminated.

[0119] In this way, the server decouples streaming message validation from business push through the collaboration of different threads, ensuring that each message is only formally sent to the client after successful validation. Simultaneously, if the validation result is invalid, the server immediately terminates the sending of all subsequent messages under that request, avoiding invalid transmission.

[0120] The method provided in this embodiment effectively blocks the continuous transmission of illegal messages by verifying each streaming message and dynamically deciding whether to send subsequent messages based on the verification results, thereby avoiding unnecessary bandwidth occupation and client processing overhead.

[0121] Figure 8 This is a flowchart of Embodiment 8 of the long-connection communication method provided in this application. This long-connection communication method is applied to a long-connection communication system, which includes a client and a server. Please refer to... Figure 8 The long-connection communication method provided in this embodiment may include the following steps:

[0122] In step S801, when the client detects a long connection establishment instruction triggered by the user, it generates a query request corresponding to the user based on the client's client identifier and the user's user identifier; wherein, the query request is used to query whether the user is legitimate.

[0123] In step S802, the client sends a query request to the server;

[0124] Step S803: The server determines whether the user is legitimate based on the query request, obtains the first query result, and returns the first query result to the client;

[0125] In step S804, the client receives the first query result and determines whether to initiate a long connection communication establishment request to the server based on the first query result.

[0126] It should be noted that the specific implementation of each step in this embodiment can be referred to the aforementioned embodiment, and will not be repeated here.

[0127] The present embodiment will now be described and illustrated through preferred embodiments.

[0128] Figure 9 The flowchart of Embodiment Nine of the long-connection communication method provided in this application is as follows: Figure 9 As shown, this long-connection communication method includes the following steps:

[0129] In step S901, when the client detects a long connection establishment instruction triggered by the user, it generates a query request corresponding to the user based on the client's client identifier and the user's user identifier, and sends the query request to the server; wherein, the query request is used to query whether the user is legitimate.

[0130] In step S902, the server determines whether the user is legitimate based on the query request, obtains the first query result, and returns the first query result to the client.

[0131] In step S903, the client receives the first query result and extracts the target field used to characterize whether the user is legitimate from the first query result; when the target field indicates that the user is legitimate, the client initiates a long connection communication establishment request to the server; when the target field indicates that the user is illegitimate, the client abandons the operation of initiating a long connection communication establishment request to the server and outputs a first reminder message; wherein, the first reminder message is used to prompt the user that the user is illegitimate.

[0132] Step S904: After receiving the client's long connection communication establishment request and successfully establishing a long connection communication with the client, the server responds to the specified service request sent by the client by sequentially sending each streaming message corresponding to the specified service request to the client, and receives the verification result of the streaming message returned by the client after sending each streaming message; wherein, the verification result is used to characterize whether each streaming message is valid.

[0133] Step S905: The server determines whether to continue sending subsequent streaming messages under the specified business request to the client based on the verification result; wherein, the subsequent streaming messages include all unsent streaming messages in all streaming messages corresponding to the specified business request.

[0134] It should be noted that the steps shown in the above process or in the flowchart of the accompanying figures can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0135] This embodiment also provides a communication system. The system in this embodiment is used to implement the above embodiments and preferred embodiments, and will not be repeated hereafter.

[0136] Figure 10 This is a structural block diagram of the communication system provided in this application. Please refer to... Figure 10 The communication system includes client 1 and server 2; wherein,

[0137] Client 1 is used to generate a query request corresponding to the user based on the client's client identifier and the user's user identifier when a long connection establishment instruction triggered by the user is detected; the query request is used to query whether the user is legitimate.

[0138] Client 1 is also used to send query requests to server 2;

[0139] Server 2 is used to determine whether a user is legitimate based on the query request, obtain the first query result, and return the first query result to client 1;

[0140] Client 1 is also used to receive the first query result and determine whether to initiate a long connection communication establishment request to server 2 based on the first query result.

[0141] This embodiment also provides a client. Figure 11 This is a structural block diagram of the client in this embodiment. Please refer to it. Figure 11 The client includes:

[0142] The generation module 11 is used to generate a query request corresponding to the user based on the client's client identifier and the user's user identifier when a long connection establishment instruction triggered by the user is detected; wherein, the query request is used to query whether the user is legitimate.

[0143] Query module 12 is used to send a query request to the server so that the server can determine whether the user is legitimate based on the query request, obtain the first query result, and return the first query result to the client;

[0144] The judgment module 13 is used to receive the first query result and determine whether to initiate a long connection communication establishment request to the server based on the first query result.

[0145] This client is used to implement the corresponding embodiments and preferred embodiments described above, and will not be repeated hereafter.

[0146] This embodiment also provides a server. Figure 12 This is a structural block diagram of the server in this embodiment. Please refer to it. Figure 12 The server includes:

[0147] The verification module 21 is used to determine whether the user corresponding to the query request is legitimate when a query request is received from the client, and to obtain the first query result; wherein, the query request is generated by the client based on the client's client identifier and the user's user identifier when the client detects the long connection establishment instruction triggered by the user and sends it to the server.

[0148] The sending module 22 is used to send the first query result to the client so that the client can determine whether to initiate a long connection communication establishment request to the server based on the first query result.

[0149] This server is used to implement the corresponding embodiments and preferred embodiments described above, and will not be repeated hereafter.

[0150] It should be understood that the specific embodiments described herein are merely illustrative of the application and not intended to limit it. All other embodiments derived by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0151] Obviously, the accompanying drawings are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar situations based on these drawings without any creative effort. Furthermore, it is understood that although the work done in this development process may be complex and lengthy, for those skilled in the art, certain design, manufacturing, or production modifications made based on the technical content disclosed in this application are merely conventional technical means and should not be considered as insufficient disclosure of this application.

[0152] The term "embodiment" in this application refers to a specific feature, structure, or characteristic described in connection with an embodiment that may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily imply the same embodiment, nor does it imply that it is mutually exclusive with or independent of other embodiments. It will be clearly or implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0153] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of patent protection. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the appended claims.

Claims

1. A long-connection communication method, characterized in that, The long-connection communication method is applied to the client; the long-connection communication method includes: When a long connection establishment command triggered by a user is detected, a query request corresponding to the user is generated based on the client's client identifier and the user's user identifier; wherein, the query request is used to query whether the user is legitimate; The query request is sent to the server, so that the server determines whether the user is legitimate based on the query request, obtains a first query result, and returns the first query result to the client; Receive the first query result and determine whether to initiate a long connection communication establishment request to the server based on the first query result.

2. The long-connection communication method according to claim 1, characterized in that, The step of determining whether to initiate a long connection communication establishment request to the server based on the first query result includes: Extract the target field from the first query result to characterize whether the user is legitimate; When the target field indicates that the user is legitimate, a long connection communication establishment request is initiated to the server; When the target field indicates that the user is illegitimate, the operation of initiating a long connection communication establishment request to the server is abandoned, and a first reminder message is output; wherein, the first reminder message is used to indicate that the user is illegitimate.

3. The long-connection communication method according to claim 1, characterized in that, After receiving the first query result, the method further includes: The first query result is cached in the first database.

4. The long-connection communication method according to claim 3, characterized in that, Before generating the query request corresponding to the user based on the client's client identifier and the user's user identifier, the method further includes: Check if the target query result corresponding to the user exists in the first database; When the target query result corresponding to the user exists in the first database, and the target query result indicates that the user is legitimate, a long connection communication establishment request is initiated to the server. If the target query result corresponding to the user does not exist in the first database, or if the target query result corresponding to the user exists in the first database and the target query result indicates that the user is illegitimate, the query request is generated based on the client's client identifier and the user's user identifier.

5. The long-connection communication method according to claim 1, characterized in that, After successfully establishing a long-lived connection with the server, the long-lived connection communication method further includes: Upon receiving each streaming message sent by the server in response to a specified business request, the streaming message is validated to obtain a validation result for each streaming message; wherein, the validation result is used to characterize whether each streaming message is valid. The verification result is returned to the server, so that the server can determine whether to send subsequent streaming messages under the specified service request to the client based on the verification result; wherein, the subsequent streaming messages include all unsent streaming messages in all streaming messages corresponding to the specified service request.

6. A long-connection communication method, characterized in that, The long-connection communication method is applied to a server; the long-connection communication method includes: Upon receiving a query request from a client, the system determines whether the user corresponding to the query request is legitimate based on the query request, and obtains a first query result. The query request is generated by the client based on the client's client identifier and the user's user identifier when the client detects a long connection establishment instruction triggered by the user, and then sends it to the server. The first query result is sent to the client so that the client can determine whether to initiate a long connection communication establishment request to the server based on the first query result.

7. The long-connection communication method according to claim 6, characterized in that, After successfully establishing a long-connection communication with the client, the long-connection communication method further includes: In response to a specified service request sent by the client, after sequentially sending each streaming message corresponding to the specified service request to the client, the system receives the verification result of each streaming message returned by the client; wherein, the verification result is used to characterize whether each streaming message is valid. Based on the verification result, determine whether to continue sending subsequent streaming messages under the specified service request to the client; wherein, the subsequent streaming messages include all unsent streaming messages in all streaming messages corresponding to the specified service request.

8. The long-connection communication method according to claim 6, characterized in that, The query request carries the client identifier and the user identifier; The step of determining whether the user corresponding to the query request is legitimate based on the query request includes: Extract the client identifier from the query request, and verify the legitimacy of the client based on the client identifier to obtain a first verification result; If the first verification result indicates that the client is illegitimate, then the user is determined to be illegitimate. When the first verification result indicates that the client is legitimate, the user identifier is extracted from the query request; The legitimacy of the user is verified based on the user identifier to obtain a second verification result, and the legitimacy of the user is determined based on the second verification result.

9. The long-connection communication method according to claim 7, characterized in that, The step of determining whether to continue sending subsequent streaming messages under the specified service request to the client based on the verification result includes: When the verification result indicates that each streaming message is valid, the client continues to receive subsequent streaming messages under the specified service request. When the verification result indicates that each streaming message is invalid, the sending of subsequent streaming messages under the specified service request to the client is stopped.

10. A long-connection communication method, characterized in that, The long-connection communication method is applied to a long-connection communication system; the long-connection communication system includes a client and a server; the long-connection communication method includes: When the client detects a long connection establishment instruction triggered by the user, it generates a query request corresponding to the user based on the client's client identifier and the user's user identifier; wherein, the query request is used to query whether the user is legitimate; The client sends the query request to the server; The server determines whether the user is legitimate based on the query request, obtains a first query result, and returns the first query result to the client; The client receives the first query result and determines whether to initiate a long connection communication establishment request to the server based on the first query result.

11. A communication system, characterized in that, The communication system includes a client and a server; wherein, The client is configured to generate a query request corresponding to the user based on the client identifier of the client and the user identifier of the user when a long connection establishment instruction triggered by the user is detected; wherein, the query request is used to query whether the user is legitimate; The client is also used to send the query request to the server; The server is configured to determine whether the user is legitimate based on the query request, obtain a first query result, and return the first query result to the client. The client is also configured to receive the first query result and determine whether to initiate a long connection communication establishment request to the server based on the first query result.

12. A client, characterized in that, The client includes: The generation module is used to generate a query request corresponding to the user based on the client identifier of the client and the user identifier of the user when a long connection establishment instruction triggered by the user is detected; wherein, the query request is used to query whether the user is legitimate; The query module is used to send the query request to the server, so that the server determines whether the user is legitimate based on the query request, obtains a first query result, and returns the first query result to the client; The judgment module is used to receive the first query result and determine whether to initiate a long connection communication establishment request to the server based on the first query result.

13. A server, characterized in that, The server includes: The verification module is used to determine whether the user corresponding to the query request is legitimate based on the query request when a query request is received from the client, and to obtain a first query result; wherein, the query request is generated by the client based on the client's client identifier and the user's user identifier when the client detects the long connection establishment instruction triggered by the user and sends it to the server; The sending module is used to send the first query result to the client, so that the client can determine whether to initiate a long connection communication establishment request to the server based on the first query result.

Images