RPC (Remote Procedure Call) system implementation method

Abstract

The invention discloses an RPC (Remote Procedure Call) system implementation method, which relates to the technical field of network communication, and comprises the following steps: after a client and a server establish a connection, when the client does not receive the heartbeat of the server for N continuous times, the client actively disconnects the connection; and when the server does not receive the heartbeat of the client for continuous N times, the server actively disconnects. The technical problem of unstable connection caused by network fluctuation or abnormal communication between the client and the server in the existing RPC system is solved, and the technical effect of ensuring the connection stability between the client and the server under the condition of network fluctuation or abnormal communication is achieved by introducing a double-end keep-alive mechanism.

Description

Technical Field

[0001] The present application relates to the field of network communication technology, and in particular to a method for implementing an RPC system. Background Art

[0002] With the widespread application of distributed systems and microservice architectures, RPC (remote procedure call) has become an important means of achieving communication between different systems in modern computing environments. However, with the increasing complexity of the network environment, the connection between the client and the server is often affected by network fluctuations and communication interruptions, resulting in unstable connections, which in turn affects the reliability of data transmission and the stability of the system. In the prior art, RPC systems usually rely on the monitoring of the underlying connection status or the reliability of the transport layer protocol, and lack an effective two-way connection stability management mechanism. In addition, many systems fail to effectively handle the scheduling of tasks of different priorities, resulting in delays in the processing of emergency tasks and affecting the overall system efficiency. Therefore, how to improve the connection stability and reliability of the RPC system while efficiently scheduling tasks has become a technical problem that needs to be solved.

[0003] In the current related technologies, there is a technical problem that the connection between the client and the server in the RPC system is unstable due to network fluctuations or communication anomalies. Summary of the invention

[0004] The present application solves the technical problem of unstable connection between the client and the server due to network fluctuations or communication anomalies in the existing RPC system by providing an RPC system implementation method.

[0005] The present application provides an RPC system implementation method, including:

[0006] Applied to an RPC system, the system includes a client and a server, a connection is established between the client and the server; when the client fails to receive a heartbeat from the server for N consecutive times, the client actively disconnects from the server; when the server fails to receive a heartbeat from the client for N consecutive times, the server actively disconnects from the client.

[0007] The present application proposes an RPC system implementation method. First, after the client and the server establish a connection, when the client does not receive the server's heartbeat for N consecutive times, the client actively disconnects the connection; when the server does not receive the client's heartbeat for N consecutive times, the server actively disconnects the connection. By introducing a dual-end keep-alive mechanism, the technical effect of ensuring the stability of the connection between the client and the server in the event of network fluctuations or communication anomalies is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 A flowchart of an RPC system implementation method provided in an embodiment of the present application;

[0009] Figure 2 A schematic diagram of a client process of a two-way keep-alive mechanism of an RPC system implementation method provided in an embodiment of the present application;

[0010] Figure 3 A schematic diagram of a two-way keep-alive mechanism server process of an RPC system implementation method provided in an embodiment of the present application;

[0011] Figure 4 A schematic diagram of a priority task scheduling process of an RPC system implementation method provided in an embodiment of the present application;

[0012] Figure 5 A schematic diagram of a reliable transmission processing flow of an RPC system implementation method provided in an embodiment of the present application;

[0013] Figure 6 A schematic diagram of a data accuracy assurance processing flow for an RPC system implementation method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0014] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below.

[0015] 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 in conjunction with the accompanying drawings. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of this application.

[0016] In the following description, reference is made to "some embodiments", which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict, and the terms "first\second" involved are merely to distinguish similar objects and do not represent a specific ordering of objects. The terms "including" and "having" and any variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or modules that are not clearly listed or inherent to these processes, methods, products, or devices. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those generally understood by technicians in the technical field of this application. The terms used herein are for the purpose of describing the embodiments of the present application only.

[0017] The present application embodiment provides a method for implementing an RPC system, such as Figure 1 As shown, the method includes:

[0018] Step S100 is applied to an RPC system, and the system includes a client and a server, and a connection is established between the client and the server. Specifically, in the RPC system, a connection is first established between the client and the server, which is implemented through a transmission protocol such as TCP. When the connection is established, the client sends a connection request and verifies the identity of the server. The server responds to the request and establishes a session with the client to ensure that both parties can exchange information safely. In this process, the two parties will exchange necessary initial information, such as version number, supported protocol type, etc., to ensure the validity of the communication link. After the connection is successful, the heartbeat mechanism is introduced to ensure the continued activity of the connection. The client regularly sends a heartbeat signal to the server. After receiving the heartbeat, the server returns a confirmation message to prove that it is active. If the client does not receive a heartbeat response from the server for N consecutive times, it means that there may be network delays, server failures or other problems. At this time, the client will actively disconnect from the server to avoid continuing to occupy system resources. On the contrary, if the server does not receive the client's heartbeat for N consecutive times, it indicates that the client may fail or drop the line, and the server will also actively disconnect to prevent invalid connections from occupying server resources. Through the heartbeat mechanism and active disconnection, the RPC system can effectively ensure the stability of the connection between the client and the server, avoiding resource waste or delays caused by network fluctuations, server failures or abnormal client disconnection. This is especially important for long-term connections in distributed systems, ensuring that system resources are used reasonably and improving overall communication efficiency.

[0019] In a possible implementation, it is applied to an RPC system, the system includes a client and a server, a connection is established between the client and the server, and step S100 further includes step S110, sending a heartbeat connection request and a business connection request to the server through the client. Specifically, in the RPC system, when the client establishes a connection with the server, the client first sends a heartbeat connection request. The role of the heartbeat connection request is to detect the reachability of the server and the stability of the communication link. For example, the client sends a heartbeat request with a current timestamp and a client ID, and the server confirms the client's connection by returning a response after receiving it. If the server does not respond to the heartbeat request within the specified timeout period, the client can decide whether to retry the connection or terminate the connection and return an error prompt according to the set rules. At the same time, the client will also send a business connection request, which contains information about the specific business operations that need to be performed, such as querying a certain data, calling a remote procedure, etc. The business connection request is usually accompanied by authentication information to ensure the legitimacy of the client's identity, such as using a token or API key, etc., to prevent unauthorized access. Once a business request is sent, the client expects the server to process it and return the corresponding result. After receiving the business connection request, the server will perform identity authentication, parameter verification, and prepare to perform specific operations. At this time, the server returns a confirmation message to the client, indicating that it is ready to process subsequent business requests. Through the collaborative mechanism of heartbeat and business connection request, the client can ensure the availability of the server and clarify the operations it needs to perform, ensuring the stability of the connection and the smoothness of business interaction.

[0020] Step S120, after receiving the heartbeat connection request and the business connection request, the server establishes a connection with the client. Specifically, after receiving the heartbeat connection request and the business connection request sent by the client, the server first processes the heartbeat connection request, and confirms the connection status of the client by parsing the client identifier, timestamp and connection request flag therein. If the client's connection is normal, the server returns a heartbeat confirmation message to ensure that the client knows the availability of the server. Then, the server parses the business connection request, checks the authentication information, request parameters and data integrity therein, and verifies whether the client has the authority to make a business request. If the verification is successful, the server allocates the required resources to the client and establishes a business session. For example, if the client requests to perform a data processing task, the server allocates computing resources according to the business request and starts the processing logic, returns the result after the processing is completed, and closes or maintains the connection in a timely manner. Through this series of operations, the server effectively guarantees the stability of the connection and the legitimacy of the business request.

[0021] In a possible implementation, it is applied to an RPC system, the system includes a client and a server, a connection is established between the client and the server, step S100 further includes step S130, the client sends a heartbeat data to the server every k seconds, and when the server receives the client heartbeat data, it replies a heartbeat data to the client. Specifically, in this scheme, the client sends a heartbeat data packet to the server at a fixed time interval (for example, k seconds), the purpose is to ensure that the connection between the client and the server is still in an active state. Each heartbeat data packet usually includes the identification information of the client, the current timestamp, and some connection status information that may be included. This process prevents the connection from being misjudged as disconnected in the case of no actual data transmission for a long time through regular heartbeat checks. After receiving the heartbeat data packet from the client, the server will first verify the validity and integrity of the data packet to ensure that the timestamp is within a reasonable range and the client identity is legal. After the verification is passed, the server will send a heartbeat confirmation packet to the client to confirm that the connection is still valid. This confirmation packet usually includes the timestamp, status information of the server and a confirmation message for the client connection. Through this two-way heartbeat mechanism, the client and server can ensure that the connection is active, thus avoiding the connection being disconnected incorrectly after a long period of idleness. For example, suppose the client sends a heartbeat packet to the server every 5 seconds, and the server returns a confirmation packet each time after receiving the heartbeat packet. If the client does not receive a confirmation from the server within the predetermined timeout period, it can choose to retry the connection or disconnect, ensuring that the system can run efficiently and stably, and avoiding connection failures caused by network fluctuations or other reasons.

[0022] In one possible implementation, Figure 4As shown, it is applied to an RPC system, the system includes a client and a server, a connection is established between the client and the server, step S100 further includes step S140, the client dyes the business data according to the business data priority and sends it to the server. Specifically, the client "dye" the business data according to its priority, and sends the data with priority information to the server. First, the client needs to prioritize all business data to be processed, and these priorities can be determined based on a variety of factors. For example, in a medical system, the imaging data of emergency patients may be assigned a high priority, while the imaging data of ordinary examinations belongs to a low priority. In order to achieve this division, the client specifies a priority identifier for each piece of data, which is usually represented by a number or color, such as "Priority: High" marked in red or marked as 1, and high-priority tasks need to be processed quickly. Next, the client "dye" the data according to the priority information of the data, that is, attach a priority field in the header or metadata of the data packet to indicate the importance and urgency of the data. This "dyeing" process ensures that the priority information of the data can be clearly identified during the transmission process. Finally, the client sends the business data with priority information to the server, and the data packet contains a clear priority tag, such as "Priority: High" or "Priority: Low". This priority identification enables the server to process the data in a timely manner according to the priority level after receiving the data, thereby improving the processing efficiency and response speed of the system.

[0023] Step S150, the server constructs a business data coloring bucket according to the business data coloring type, stores the business data, and then processes it in sequence according to the coloring bucket priority and replies to the client. Specifically, after receiving the business data sent by the client, the server will first classify and store it in different "coloring buckets" according to the priority of the data. Each coloring bucket represents a data set of a priority level. For example, high-priority data is placed in a bucket named "High_Priority", while low-priority data is placed in a "Low_Priority" bucket. The data in each bucket is arranged in the order of receipt, and it is ensured that no data is lost or damaged during storage. The server processes the data in these coloring buckets in sequence according to priority, and data with high priority will be processed first. For example, when the server receives a high-priority task from the client (such as an emergency medical data processing request), the data will be processed quickly and the response result will be returned, while low-priority tasks (such as data processing of some daily reports) will be processed later. This priority sorting ensures that urgent tasks can be responded to in a timely manner without delay. In addition, the server will also dynamically optimize during processing, such as temporarily raising the priority of certain tasks when the load is high, or dispatching more resources to speed up the processing of high-priority tasks. After the processing is completed, the server will generate processing results based on the completion of the task and return the results to the client through the network. If it is found during the processing that low-priority data requires additional operations, the server will continue to process it, ensuring that the system maintains efficient operation while taking into account the needs of different tasks. It effectively ensures that high-priority tasks are responded to in a timely manner, while low-priority tasks are not ignored, ensuring the efficient operation of the entire system.

[0024] In a possible implementation, the server constructs a business data dyeing bucket according to the business data dyeing type to store the business data, and then processes the business data in sequence according to the dyeing bucket priority and replies to the client. Step S150 further includes step S151. When the priority of the inserted business data is higher than the priority of the queued business data, public resources are preferentially allocated to the inserted business data on the premise that the queued business data can be processed. Specifically, when processing business data, the server allocates resources according to the priority of each task. When the priority of the inserted business data is higher than the current queued business data, the server first confirms whether the data in the queue is still processable to ensure that they are not completely postponed due to the insertion of high-priority tasks. If the queued task can still be processed, the server allocates more computing resources and bandwidth to the inserted high-priority task, thereby accelerating its processing speed. For example, when the system receives an urgent task (such as emergency patient data in a medical system), it will give priority to using the server's computing power to process the task instead of waiting for regular tasks in the queue. At the same time, the server will not ignore low-priority tasks in the queue. It will allocate sufficient computing resources according to the availability of resources to ensure that these tasks are processed in a timely manner. In this way, even if high-priority tasks occupy more resources, low-priority tasks can be executed within a certain period of time to avoid task blocking or delays. In order to maintain the balance of the system, the server will also dynamically adjust resource allocation to ensure that after the high-priority tasks are completed, the remaining resources can be reallocated to the queued tasks. For example, after the emergency task is processed, the server will immediately put the unprocessed low-priority tasks back into the processing queue to ensure the efficient operation of the entire system. This priority scheduling mechanism can not only respond quickly to emergency tasks, but also ensure the continuous advancement of other tasks, thereby achieving efficient and balanced task processing.

[0025] In a possible implementation, it is applied to an RPC system, the system includes a client and a server, a connection is established between the client and the server, step S100 further includes step S160, the client and the server are connected via a TCP transmission protocol, the TCP transmission protocol includes: a protocol identifier, an operation identifier, a session identifier, a total number of message fragments, a current number of message fragments, a message type, a content length, a message content summary, and a transmission data content. Specifically, the client and the server communicate via the TCP transmission protocol to ensure reliable data transmission. Each time a connection is established between the client and the server, data is exchanged according to a series of fields defined by the TCP protocol. The protocol identifier is used to distinguish different communication protocols to ensure that data can be correctly transmitted to the target application. Next, the operation identifier determines the specific operation type of the data packet, such as a request or a response, so that the server knows how to process the client's request. The session identifier is used to distinguish different sessions, which helps the server identify concurrent requests from different clients to avoid confusion. During data transmission, if a data packet is too large and needs to be fragmented, the total number of message fragments and the current number of message fragments fields will be added to each data packet to ensure that the receiver can correctly reassemble the data after receiving all the fragments. For example, when the file sent by the client is split into multiple small pieces, each small piece will be accompanied by this information, and the server can restore the file in order based on the information. The message type field helps the client and the server identify the purpose of the data packet, such as request data, response result, or error prompt, so as to take corresponding processing. The content length field indicates the length of the valid data in the data packet, helping the receiver to read the data correctly and avoid data loss or error. The message content summary is used for data integrity verification. When sending data, the client will calculate the content summary and attach it to the data packet header. After receiving the data packet, the server will recalculate the summary of the data and compare it to ensure that the data has not been tampered with during transmission. If the summary matches, the server processes the data, otherwise it requires the client to resend. Finally, the content part of the transmitted data contains the actual business data. The client and the server use this field to exchange specific data, such as order information or query requests submitted by customers. Through such a design, the TCP protocol ensures that the data transmission between the client and the server is not only efficient and accurate, but also guarantees the integrity and correctness of the data under unstable network conditions.

[0026] Step S200: When the client fails to receive the server heartbeat for N consecutive times, the client actively disconnects from the server. Figure 2As shown, specifically, after the client and the server establish a connection, in order to ensure the continuity and reliability of the connection, the client will periodically receive the heartbeat signal sent by the server. When the client fails to receive the heartbeat signal from the server for N consecutive times, it means that there may be a problem with the network or a failure on the server, resulting in the inability to maintain a stable connection. Therefore, the client will actively disconnect from the server. This mechanism avoids the client waiting for a long time for the response from the server, reduces the occupation of system resources by invalid connections, and improves the efficiency and stability of the system. For example, in an actual application scenario, when the client interacts with the remote server for data, if the network is interrupted or the server crashes, the client can detect the abnormality in time through the heartbeat mechanism and quickly disconnect to avoid continuing unnecessary operations. This active disconnection mechanism can not only reduce the waiting time, but also help the client retry the connection or start the error handling process, thereby improving the reliability and response speed of the overall system. For example, in an online payment system, if the payment client fails to receive the heartbeat signal from the payment server in time, the client will immediately disconnect and notify the user of the service abnormality, avoiding the user's waiting time and freeing up resources for other operations of the system.

[0027] In one possible implementation, Figure 5 As shown, when the client fails to receive the heartbeat of the server for N consecutive times, the client actively disconnects from the server, and step S200 further includes step S210, after the client sends the service data to the server, the timer is started from 0 to obtain the timing result. Specifically, after the client sends the service data to the server, the client immediately starts a timer, and the timer starts to record the time from zero. The purpose of the timer is to track the time from the data transmission to the reception of the server response. Specifically, while sending the data packet, the client starts the timer to measure the time lapse to ensure that it waits for the response of the server within the specified time. The timer will be updated in real time and record the elapsed time, so that the client can obtain accurate timing results. This timing result is not only used to determine whether the client has received the response of the server within the preset timeout period, but also can affect the subsequent data processing behavior. For example, if the client requests the server to process a data query, the timer is started after sending the request. If the server responds within the set time, the client will stop timing and process the result; if it times out, the client can trigger the retry mechanism, resend the request or take other processing measures, thereby avoiding the inefficiency caused by long waiting. The introduction of this timing mechanism effectively improves the reliability and real-time performance of communication between the client and the server.

[0028] Step S220, when the timing result does not exceed the preset duration, the client obtains the reply data of the server, and the business data transmission is completed, and the process is stopped. Specifically, after the client sends the business data to the server, it will start the timer, start timing from 0, and record the time of data transmission. When the timing result does not exceed the preset duration, the client continues to wait for the reply data of the server. At this time, the client determines whether the server successfully replies within a reasonable time, and confirms whether the data transmission is completed. For example, after the client uploads a file, it will start the timer and wait for the confirmation reply from the server. If the confirmation information from the server is received within the predetermined time and the file is successfully uploaded, the client will stop the timer and end the upload process. If the server still does not reply, the client considers that the transmission has timed out and takes corresponding retry or disconnection measures. This mechanism ensures the efficiency and accuracy of data transmission between the client and the server, avoids the waste of resources caused by long-term non-reply, and can improve the response speed and stability of the entire system.

[0029] Step S230, when the timing result does not exceed the preset duration, the client obtains the reply data of the server, and the business data transmission is not completed, the client continues to send business data to the server. Specifically, when the client sends business data to the server, a timer is started and the timing starts from zero. In this process, the client will continue to monitor whether the server has returned the reply data. If the client receives part of the reply data from the server within the preset time, but the business data transmission is still not completed, and the time displayed by the timer has not exceeded the preset duration, the client will continue to send the remaining business data to the server. For example, suppose that the client is uploading a large file to the server. Since the file is large, the transmission process needs to be completed in multiple times. After the first data transmission, the client will check whether the server has processed part of the data and returned a reply. If within the specified time, the client receives a partial reply and confirms that the data transmission is not completed, the client will continue to send the remaining file data. In this way, even if the server has a slow processing speed or a large amount of data transmission, the client can ensure the complete transmission of the business data and avoid interruptions or errors caused by partial data transmission delays. This mechanism not only improves the efficiency of data transmission, but also ensures that the system can continue to work efficiently in the face of network fluctuations or server delays.

[0030] In a possible implementation, when the timing result does not exceed the preset time, the client obtains the reply data of the server, and the service data transmission is not completed, the client continues to send the service data to the server, and step S230 further includes step S231, when the timing result exceeds the preset time, the client does not obtain the reply data of the server, and the service data is resent to the server through the client. Specifically, when the time recorded by the timer exceeds the preset time (for example, 10 seconds), and the client fails to receive the reply data from the server, the client triggers the timeout processing mechanism. At this time, the client will determine the current business data transmission failure and decide to try to restore communication by resending the business data. Specifically, the client will prepare a business data packet that is completely consistent with the original one and resend it to the server. During retransmission, the client may use the original connection channel, or reestablish the connection when necessary to ensure that the data can reach the server smoothly. In actual applications, for example, when the client sends a file processing request to the server, if the confirmation information of the server is not received within the set 10 seconds, the client will consider that the communication has timed out and immediately resend the request file. Each time a message is resent, the client will also record the number of retransmissions and dynamically adjust subsequent operations, such as increasing the transmission interval to avoid network congestion, or optimizing the data packet structure to increase the transmission success rate. In this way, even if the network is unstable or the server is temporarily unavailable, the client can still improve the reliability of data transmission through multiple attempts, thereby ensuring the overall stability and effectiveness of the system.

[0031] Step S232, when the client still does not obtain the reply data from the server after resending the business data for more than the preset number of times, the client disconnects from the server and returns an error prompt. Specifically, when the client resends the business data after a timeout and does not receive the reply data from the server after each retransmission, the client will make a judgment based on the set maximum number of retransmissions. For example, if the system sets an upper limit of 3 retransmissions, the client will resend the business data after each timeout. Whenever the number of retransmissions does not reach the preset maximum value, the client continues to try to send data until the number reaches the upper limit. If the client still does not receive a response from the server after the maximum number of retransmissions, the client will think that the connection has a serious fault and cannot be restored to a normal communication state, and the disconnection mechanism will be triggered. At this time, the client actively disconnects from the server to ensure that no more resources will be wasted or more invalid data transmission will be generated. After disconnecting, the client will return an error prompt to the user to inform the user that the operation failed, such as "network connection timeout, please try again later" or "unable to establish a connection with the payment server, payment failed", etc., to help the user understand the problem and take corresponding measures. In an online payment scenario, this mechanism ensures that users do not receive misleading results after a long wait, but instead clearly know that there was a network problem and need to retry the payment.

[0032] In one possible implementation, Figure 6As shown, when the client fails to receive the heartbeat of the server for N consecutive times, the client actively disconnects from the server, and step S200 further includes step S240, in which the client calculates the summary of the business data and fills it into the header information of the business data to transmit it to the server. Specifically, the client first generates the business data to be transmitted, which may be text, pictures or other forms of files, and is packaged and encoded according to business needs. Then, the client uses a hash algorithm (such as SHA-256 or MD5) to calculate the summary of the data content and generate a hash value of a fixed length, which is called a "summary" or "checksum", which can uniquely identify the data content and ensure the integrity of the data. Then, the client fills the calculated summary into the header information of the data packet, and the header information generally includes fields such as protocol version, data length, source and destination information. The business data filled with the summary is sent to the server via a network transmission protocol (such as TCP, UDP, HTTP, etc.). After receiving the data packet, the server extracts the summary information of the header, and recalculates the data content using the same hash algorithm to obtain a new summary, and then compares it with the summary sent by the client. If the two are consistent, it means that the data has not been tampered with, and the server can continue to process the data; if they are inconsistent, it means that the data may have been lost, damaged or tampered with during transmission, and the server will discard the data and request the client to resend it. For example, suppose the client needs to send a user order, including user ID, product list and amount information. The client calculates the summary of the order data and puts it into the data packet header. After the server receives the data, it recalculates the summary of the content and compares it with the client's summary. If the data is consistent, the server will process the order; if the data has been tampered with (for example, the amount field has been modified) and the summary is inconsistent, the server will refuse to process it and request the client to resend the data.

[0033] Step S250, when the server receives the business data, it extracts the header summary information, sets it as the benchmark summary information, calculates the summary of the business data content, and sets it as the comparison summary information. Specifically, when the client sends the business data to the server, the data packet not only contains the actual business data, but also adds the summary information calculated by the client and filled in the header. After receiving the data, the server first extracts the summary information attached by the client from the data packet and sets it as the benchmark summary information. Subsequently, the server processes the received business data, uses the same hash algorithm as the client (such as SHA-256 or MD5) to perform a summary calculation on the content part of the business data, and obtains the comparison summary information. Then, the server compares the benchmark summary information with the comparison summary information. If the two summary information are consistent, it means that the data has not been tampered with during the transmission process, and the server can continue to process the business data; if the comparison results are inconsistent, it means that the data may be tampered with, lost or damaged during the transmission process, and the server will delete the business data and require the client to resend it. For example, in a payment system, the client will send business data containing transaction amount, user information and payment method. Before sending data, the client will calculate a hash value and attach it to the header of the data packet. After receiving the data, the server will compare the hash value of the business data with the hash value sent by the client. If they are consistent, the server will confirm the integrity of the data and continue to process the payment request; if they are inconsistent, the server will believe that the data has been tampered with or lost and require the client to resend the payment information.

[0034] Step S260, the server compares the benchmark summary information and the comparison summary information. When the comparison results are consistent, the service data is processed. When the comparison results are inconsistent, the service data is deleted. Specifically, after receiving the service data transmitted by the client, the server first extracts the summary information attached to the client from the header of the data packet. This summary information is a hash value calculated by the client according to the data content before sending the service data, which is used as the benchmark summary information for verifying the integrity of the data. Next, the server performs the same hash calculation on the received service data content to obtain a comparison summary information. This comparison summary information is compared with the benchmark summary information sent by the client. If the comparison results are consistent, it means that the service data has not been tampered with or lost during the transmission process. After confirming the integrity of the data, the server will continue to process the data, such as performing business operations, updating database records or other related processing. If the comparison results are inconsistent, it means that the data may be tampered with or damaged during the transmission process. The server will consider the data unreliable, so it will delete the received service data and may return an error message to the client or request to resend the data. For example, if the client sends a payment request and the server finds that the summary information is inconsistent when verifying the data, the server will abort the request to avoid incorrect transaction processing and send a resend request to the client to ensure the data security and integrity of the entire transaction process.

[0035] In a possible implementation, the server compares the reference summary information and the comparison summary information, and when the comparison results are consistent, processes the business data, and when the comparison results are inconsistent, deletes the business data. Step S260 further includes step S261, the server calculates the summary of the reply data and fills it into the header information of the reply data to transmit to the client. Specifically, after receiving the business data sent by the client, the server will perform a summary calculation on the reply data to be sent, usually using a hash algorithm such as SHA-256 or MD5 to generate a summary value of the data. The summary value plays a role in data integrity verification during data transmission. The calculated summary value will be filled into the header field of the reply data to ensure that the summary information can be extracted and used when the client receives the data. For example, the client may request to query the status of an order. After processing the request and querying the order status, the server will generate reply data containing the status information and calculate the summary of the status data. The server fills the calculated summary into the header field of the reply data, and then sends the entire reply data (including business content and summary information) to the client. After receiving the data, the client extracts the summary information in the reply data header, calculates the summary value of the received business data content, and compares them. If the two summary values ​​are consistent, it means that the data has not been tampered with during transmission, and the client continues to process the business data; if the summary values ​​are inconsistent, it means that the data may have been tampered with or damaged, and the client will request to retransmit the data. In this way, the data transmission security between the server and the client is guaranteed, ensuring the integrity and accuracy of the business data.

[0036] Step S262, when the client receives the reply data, it extracts the reply data header summary information, sets it as the reply data benchmark summary information, and calculates the summary of the reply data content, which is set as the reply data comparison summary information. Specifically, when the client receives the reply data from the server, it first extracts the summary information in the reply data header. This part of information is called "reply data benchmark summary information", which is the summary calculated and attached to the data header by the server when sending data. Then, the client performs a hash calculation on the actual content part of the reply data to generate a new summary value. This calculation result is called "reply data comparison summary information". The client compares the two summary values. If the two summary values ​​are completely consistent, it means that the data has not been changed or damaged during the transmission process. The client can confirm that the business data is complete and has not been tampered with, and then continue with subsequent data processing. If the comparison result finds that the summary values ​​are inconsistent, the client will think that the data may be tampered with or damaged during the transmission process. At this time, the client may request the server to retransmit the data or trigger an alarm mechanism according to the set processing strategy to ensure the integrity and accuracy of the received data. For example, in a financial transaction system with high security requirements, the client requests account balance data from the server, and the data replied by the server contains the latest balance of the account. In the above process, the client performs digest verification on the received balance data to confirm that the data has not been tampered with. If the digest verification fails, the data will not be processed to prevent the wrong information from being used in subsequent operations.

[0037] Step S263, the client compares the reply data benchmark summary information with the reply data comparison summary information. When the comparison results are consistent, the business data processing is deemed to be completed. When the comparison results are inconsistent, the business data is retransmitted to the server. Specifically, after receiving the reply data from the server, the client first extracts the benchmark summary information attached to the data header, and the server calculates the generated summary value based on the content before sending the data. At the same time, the client independently calculates its summary information based on the received complete reply data content to generate the comparison summary information. Subsequently, the client compares the benchmark summary information with the comparison summary information bit by bit. If the comparison results are consistent, it means that the data maintains integrity and has not been tampered with during the transmission process. At this time, the client confirms that the business data processing has been completed. For example, in an e-commerce transaction, the client receives payment confirmation data. After confirming that the summary is consistent, the system can safely mark the transaction as completed. However, if the benchmark summary information is inconsistent with the comparison summary information, the client will determine that the data may be erroneous or tampered with during the transmission process, and then initiate a retransmission request to the server, requiring the server to resend the business data. In an online medical imaging system, if the summary verification of the imaging report received by the client fails, it will request the server to resend the report to ensure that the doctor receives a complete and accurate report. After multiple retransmissions, if the client still cannot receive the verified data, the exception handling mechanism will be triggered, such as recording an error log, prompting the user that the operation failed, or notifying the system administrator to ensure data security and the overall stability of the system. This summary comparison mechanism plays an important role in ensuring data integrity and reliability.

[0038] Step S300: When the server fails to receive the client's heartbeat for N consecutive times, the server actively disconnects from the client. Figure 3As shown, specifically, after the server establishes a connection with the client, it will start the heartbeat detection mechanism to monitor whether the client's connection status is normal. During the connection maintenance period, the server continues to wait for heartbeat data from the client at a set time interval (such as 5 seconds). If the heartbeat sent by the client is not received within N consecutive predetermined time intervals (such as N=3), the server will determine that the client may have lost connection or there is a problem with the network. At this time, the server makes a judgment by recording the counter of the number of heartbeat failures. When the counter value reaches the set threshold N, the server will actively disconnect the connection with the client and release related resources, such as memory allocation, thread occupancy, etc., to avoid long-term occupation of system resources by invalid connections. After disconnection, the server will also record a log of the disconnection event, including the client's identification, the reason for disconnection, and the specific time, for subsequent analysis or troubleshooting. In some application scenarios, after disconnection, the server may trigger a retry mechanism. For example, in a distributed task scheduling system, the master node will try to resend the heartbeat signal or initiate a reconnection request to ensure that the client can quickly rejoin the task allocation queue after returning to normal. In addition, in real-time communication systems (such as online education platforms), when the server disconnects a student client, it may also notify the classroom management module to update the online status to ensure that the system data is consistent with the actual situation. Through the above mechanism, the server can effectively avoid resource waste, improve system stability and operating efficiency, and provide data support for subsequent fault recovery.

[0039] In the embodiment of the present application, after the client and the server establish a connection, when the client does not receive the server's heartbeat for N consecutive times, the client actively disconnects the connection; when the server does not receive the client's heartbeat for N consecutive times, the server actively disconnects the connection, thereby achieving the technical effect of ensuring the stability of the connection between the client and the server in the event of network fluctuations or communication anomalies by introducing a dual-end keep-alive mechanism.

[0040] The above specific implementations do not constitute a limitation on the protection scope of this application. It should be understood by those skilled in the art that various modifications, combinations and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of this application should be included in the protection scope of this application.

Claims

1. A method for implementing an RPC system, characterized in that: Applied to an RPC system, the system includes a client and a server, after the client and the server establish a connection, it includes: When the client fails to receive the server's heartbeat for N consecutive times, the client actively disconnects from the server; When the server fails to receive the client's heartbeat for N consecutive times, the server actively disconnects from the client.

2. The method according to claim 1, characterized in that The client and server establish a connection, including: Send heartbeat connection requests and business connection requests to the server through the client; After receiving the heartbeat connection request and the service connection request, the server establishes a connection with the client.

3. The method according to claim 1, characterized in that After the connection is established between the client and the server, it also includes: The client sends a heartbeat data to the server every k seconds. After receiving the heartbeat data from the client, the server replies with a heartbeat data to the client.

4. The method according to claim 1, characterized in that Also includes: The client colors the business data according to the business data priority and sends the data to the server; The server constructs a business data coloring bucket according to the business data coloring type to store the business data, processes the business data in sequence according to the coloring bucket priority, and then replies to the client.

5. The method according to claim 4, characterized in that The server constructs a business data coloring bucket according to the business data coloring type to store the business data and then processes it in sequence according to the priority, including: When the priority of the inserted service data is higher than the priority of the queued service data, public resources are preferentially allocated to the inserted service data on the premise that the queued service data can be processed.

6. The method according to claim 1, characterized in that Also includes: After the client sends the service data to the server, the timer is started from 0 to obtain the timing result; When the timing result does not exceed the preset time, the client obtains the reply data from the server, and the service data transmission is completed, the process is stopped; When the timing result does not exceed the preset time length, the client obtains the reply data from the server, and the service data transmission is not completed, the client continues to send the service data to the server.

7. The method according to claim 6, characterized in that Also includes: When the timing result exceeds the preset time length, the client does not obtain the reply data of the server, and the service data is resent to the server through the client; When the service data is resent more than a preset number of times and the client still does not obtain the reply data from the server, the client disconnects from the server and returns an error prompt.

8. The method according to claim 1, characterized in that Also includes: The client calculates a summary of the service data, fills it into the service data header information, and transmits it to the server; When the service end receives the service data, it extracts the header summary information and sets it as the reference summary information, and calculates the summary of the service data content and sets it as the comparison summary information; The server compares the benchmark summary information with the comparison summary information, and processes the business data when the comparison results are consistent, and deletes the business data when the comparison results are inconsistent.

9. The method according to claim 8, characterized in that Also includes: The server calculates a summary of the reply data, fills it into the reply data header information, and transmits it to the client; When the client receives the reply data, it extracts the reply data header summary information, sets it as the reply data reference summary information, and calculates the summary of the reply data content, sets it as the reply data comparison summary information; The client compares the reply data benchmark summary information with the reply data comparison summary information. When the comparison results are consistent, it is considered that the business data processing is completed. When the comparison results are inconsistent, the business data is retransmitted to the server.

10. The method according to claim 1, characterized in that The client and the server are connected via the TCP transmission protocol, which includes: protocol identifier, operation identifier, session identifier, total number of message fragments, current number of message fragments, message type, content length, message content summary and transmission data content.

Images