Multi-thread RPC server based on Sun RPC

Abstract

The invention discloses a multi-thread RPC (Remote Procedure Call) server based on Sun RPC (Remote Procedure Call), which is characterized in that new connection of the server is monitored, the Sun RPC is utilized to record related information of a newly connected client, then the new connection is identified from all client sets provided by the Sun RPC, and a sub-thread special for processing a service request of the client is created for the new connection; therefore, the multi-thread RPC server capable of processing multiple clients at the same time is realized. Wherein the sub-threads are processed according to the process of the Sun RPC, and the basic functions of the Sun RPC are not influenced while the service requests of multiple connections are processed by the server side. According to the scheme provided by the invention, when one connection is blocked, the processing of other connections is not influenced, so that the utilization rate of a CPU (Central Processing Unit) is improved, and the working efficiency of an RPC (Remote Procedure Call) server is improved.

Description

Technical Field

[0001] The present invention relates to an RPC server, and in particular to a technology for realizing a multi-threaded server based on a single-threaded model framework of Sun RPC in a software system. Background Art

[0002] The existing Sun RPC server is a single-threaded model framework. Every time Sun RPC receives a connection, it will process all requests one by one. If it is a single or small number of access requests, Sun RPC can generally process them in time. When multiple devices or multiple processes access the same RPC server, the processing time of the Sun RPC server will be extended, which will cause some client requests to not be responded to. This problem will be more prominent when the processing time of one of the requests is too long or high concurrency occurs in a distributed architecture. Furthermore, this situation is usually accompanied by the problem of CPU resources not being utilized and low efficiency, and at the same time affects the entire system to a greater or lesser extent.

[0003] Therefore, how to effectively improve the ability of the RPC server to handle concurrent requests is a technical problem that urgently needs to be solved in this field. Summary of the invention

[0004] In view of the problems existing in the existing Sun RPC server adopting a single-threaded model framework, the purpose of the present invention is to provide a multi-threaded RPC server implementation solution based on Sun RPC, which can effectively solve the problems of the existing RPC server in high concurrent requests and some requests taking too long resulting in other connections not being responded to.

[0005] In order to achieve the above object, the multi-threaded RPC server based on Sun RPC provided by the present invention is configured as a management thread that only monitors connection requests, and uses Sun RPC internal methods to add the file descriptor of the new connection, the event to be monitored and the returned event information to the svc_pollfd array of Sun RPC;

[0006] A newly connected client is identified from all the client information recorded by svc_pollfd, and a child thread is created for it to process the service request of this client. The child thread is configured to process according to the process of Sun RPC.

[0007] Furthermore, the multi-threaded RPC server is configured with a management thread unit and a business processing thread unit.

[0008] The management thread unit is a single thread, configured to monitor the server's connection request and create a corresponding service thread for each client. The basic process follows the original process of Sun RPC.

[0009] The business processing thread unit is a plurality of threads, each of which is configured to process a business request of a client. The basic process follows the original process of Sun RPC, and its resources will be sold automatically after the client disconnects.

[0010] Further, the management thread unit is configured to be able to perform the following operations:

[0011] (1) Only listen to and record the server file descriptor provided by Sun RPC, the events to be listened, and the array of returned event information in a blocking waiting manner;

[0012] (2) The server file descriptor provided by Sun RPC, the array of events to be monitored, the event information returned, and the number of monitored events are handed over to Sun RPC for the next step of adding the file descriptor of the new connection, the events to be monitored, and the event information returned to the svc_pollfd array;

[0013] (3) Create a child thread for the new connection to process the service request, and notify the child thread of the file descriptor of the new connection and the location of the event;

[0014] (4) When the RPC server is shut down, all child threads that are still connected are destroyed.

[0015] Furthermore, when the management thread unit creates a subthread for processing a service request for a new connection, the management thread unit includes:

[0016] (1) Filter out newly connected clients from the client information in the svc_pollfd array and create a service thread for them;

[0017] (2) Separate the newly created business thread.

[0018] Furthermore, the management thread unit monitors the events of the RPC server in a cyclic manner.

[0019] Furthermore, the management thread unit exits the loop when an error occurs during monitoring, and terminates the RPC server after destroying all child threads.

[0020] Furthermore, the business processing thread unit is configured to be able to perform the following operations:

[0021] (1) Obtain the file descriptor and event of the new connection, and perform blocking listening on the new connection obtained;

[0022] (2) After monitoring the service request, it submits the request to Sun RPC for server-side service;

[0023] (3) When the client disconnects, the corresponding business thread performs self-sale processing.

[0024] Furthermore, the acquisition of the file descriptor and other information of the new connection is to obtain the file descriptor of the service object, the events to be monitored and the returned events from the svc_pollfd array, and the position of the file descriptor and other information of the new connection in the svc_pollfd array is provided by the management thread to create the service thread.

[0025] The multi-threaded server based on Sun RPC provided by the present invention innovatively constructs a multi-threaded RPC server mechanism, increases the ability of the RPC server to process multiple connections at the same time, enables the RPC server to process multiple connection requests at the same time, and avoids affecting the processing of other connections due to one connection request.

[0026] Furthermore, the multi-threaded server based on Sun RPC provided by the present invention monitors new connections of the server and creates a child thread for it to perform business processing of a single connection. In this way, multiple connection requests can be processed simultaneously without affecting the basic operation of Sun RPC, thereby increasing the ability of the RPC server to process multiple connections simultaneously.

[0027] Furthermore, the Sun RPC-based multi-threaded server provided by the present invention can not affect the processing of other connections when one connection is blocked, thereby effectively improving the utilization rate of the CPU and improving the working efficiency of the RPC server. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The present invention is further described below in conjunction with the accompanying drawings and specific embodiments.

[0029] Figure 1 It is a flow chart of managing threads in the implementation of the present invention;

[0030] Figure 2 This is a business thread flow chart in the implementation of the present invention. DETAILED DESCRIPTION

[0031] In order to make the technical means, creative features, objectives and effects achieved by the present invention easy to understand, the present invention is further explained below with reference to specific diagrams.

[0032] Explanation of the name:

[0033] Sun RPC: An open source RPC framework developed by Sun Microsystem.

[0034] RPC: Remote Procedure Call, the client requests service processing from the service provider through the network based on a certain transmission protocol and obtains returned data.

[0035] svc_run() function: triggers the server-side service to respond based on the information of the RPC call.

[0036] poll() function: listens and waits for attribute changes of multiple file descriptors.

[0037] svc_getreq_poll() function: A function provided by Sun RPC, used to trigger a response to a server-side service. When a new connection is made, it adds the file descriptor of the new connection, the requested event, and the returned event to the svc_pollfd array, and destroys abnormal connections that have not completed any work.

[0038] Socket: An abstract concept for communication in a computer network, which provides a programming interface that can exchange data over the network.

[0039] svc_pollfd: It is an array of information provided by Sun RPC that needs to be monitored, including file descriptors of the server and client, requested events, and returned events.

[0040] The existing Sun RPC server is a single-threaded model framework, and because Sun RPC listens to all events and processes requests in sequence, it is not possible to increase the ability of the Sun RPC server to process multiple connections simultaneously by setting priorities.

[0041] In this regard, the solution of the present invention innovatively increases the ability of the RPC server to handle multiple connections simultaneously through multi-threading, thereby fully utilizing CPU resources, improving server performance, and reducing the waiting time of the client.

[0042] The solution of the present invention provides a multi-threaded RPC server based on Sun RPC, and configures the multi-threaded RPC server to be able to monitor new connections of the server through an innovative implementation mechanism, and uses the internal method of Sun RPC to add the file descriptor of the new connection, the event to be monitored and the returned event information to the svc_pollfd array of Sun RPC;

[0043] On this basis, the newly connected client is then identified from all the client information recorded by svc_pollfd, and a child thread corresponding to the business request of this client is created for the identified new connection, thereby realizing a multi-threaded RPC server that can handle multiple clients at the same time.

[0044] Furthermore, in the solution of the present invention, the subthread is configured to perform processing according to the process of Sun RPC, so that the basic functions of Sun RPC are not affected while the service end processes the service requests of multiple connections.

[0045] With respect to the above-mentioned multi-threaded RPC server based on Sun RPC, the present invention further provides a corresponding implementation mechanism. A management thread unit and a business processing thread unit are configured in the multi-threaded RPC server. The two thread units cooperate organically to realize that the server processes business requests of multiple connections without affecting the basic functions of Sun RPC.

[0046] The management thread unit is a single thread, which is configured to monitor the server's connection requests and create a corresponding service thread for each client. The basic process follows the original Sun RPC process.

[0047] The business processing thread unit consists of multiple threads, each of which is configured to be responsible for a customer's business request. The basic process follows the original Sun RPC process, and its resources can be sold after the customer disconnects.

[0048] As a further illustration, the management thread unit configured in the solution of the present invention is specifically configured to implement the corresponding functions by performing the following operations:

[0049] (1) Only listen to and record the server file descriptor provided by Sun RPC, the events to be listened, and the array of returned event information in a blocking waiting manner;

[0050] (2) The monitoring result is the number of events detected. The server file descriptor provided by Sun RPC, the events to be monitored, and the array of returned event information, as well as the monitoring result, are used as input parameters of the svc_getreq_poll() function of Sun RPC to add the file descriptor of the new connection, the events to be monitored, and the returned event information to the svc_pollfd array;

[0051] (3) Create a child thread for the newly connected client to process the service request, and notify the child thread of the location of the newly connected client information in the svc_pollfd array;

[0052] (4) When the RPC server is closed, all child threads that are still connected are destroyed. This is the normal exit process. The created resources are destroyed in sequence to avoid memory leaks.

[0053] The above-mentioned management thread unit realizes that the management thread only processes connection requests by only monitoring the server's file descriptor and other related information and combining the monitoring results as the input parameters of the svc_getreq_poll() function; by creating child threads, it realizes the processing of business requests, thereby achieving separate processing of connection requests and business requests, laying the foundation for serving multiple clients at the same time; due to the existence of operations such as creation and destruction of child threads, this unit realizes the management effect of child threads.

[0054] As a further explanation, when the management thread unit monitors the events of the RPC server in step (1), it is preferably performed in a loop. On this basis, the management thread unit exits the loop when an error occurs in the monitoring, and terminates the RPC server after destroying all child threads.

[0055] As a further explanation, the management thread unit can achieve the purpose of only being responsible for the client's connection request and not paying attention to the service request by only monitoring the server in step (1), thereby improving processing efficiency.

[0056] On this basis, since the management thread unit records the server file descriptor provided by Sun RPC, the events to be monitored and the array of returned event information in step (1), the server information has been added to the svc_pollfd array by Sun RPC before the loop monitoring starts. Therefore, the position of the server file descriptor information in the svc_pollfd array is recorded before the start, and the array for obtaining the server file descriptor information can be prepared in each loop.

[0057] As a further explanation, when the management thread unit creates a child thread for processing a service request for a new connection in the above step (3), it is implemented by the following steps:

[0058] (1) Filter out newly connected clients from the client information in the svc_pollfd array and create a business thread for them; this step only provides the svc_pollfd array for Sun RPC, in which the client information includes new connections and existing connections. Here, we filter to check whether all clients have threads dedicated to business processing;

[0059] (2) Separate the newly created business thread; by separating the threads, the memory leak problem can be effectively avoided, and the business thread can terminate itself after the client ends the business request and disconnects.

[0060] Based on the configuration scheme of the management thread unit, the business processing thread unit here interacts with the management thread unit and is specifically configured to perform the following operations:

[0061] (1) Obtain the file descriptor and event of the new connection, and perform blocking listening on the new connection obtained;

[0062] In the specific implementation of this step, the business processing thread unit accurately obtains the file descriptor and event of the new connection from the svc_pollfd array through the file descriptor and event location information of the new connection of the notified child thread when the management thread establishes the child thread.

[0063] (2) The monitoring result is the number of events detected. The file descriptor of the new connection, the event to be monitored, the returned event information and the monitoring result are used as input parameters of the svc_getreq_poll() function of Sun RPC to respond to the server-side service;

[0064] (3) When the client disconnects (i.e., the business processing is completed), the corresponding business thread performs self-sale processing.

[0065] As a further explanation, the processing flows of the management thread unit and the business processing thread unit formed here are all in line with the processing of Sun RPC, so that a multi-threaded server can be implemented without affecting the basic functions of Sun RPC.

[0066] With respect to the multi-threaded RPC server solution based on Sun RPC provided by the present invention, the implementation process and technical features of the multi-threaded RPC server solution are specifically described below.

[0067] In view of the fact that the Sun RPC server is a single-threaded model framework, the solution of the present invention implements multi-connection business processing by creatively improving the svc_run() function that monitors client requests.

[0068] The steps of the svc_run() function to monitor client requests are as follows:

[0069] (1) Create an array to record the file descriptors and events of all RPC servers and RPC connections. The above information is provided by the svc_pollfd array of SunRPC. The purpose of the array created here is to serve as the monitoring object of the poll() function.

[0070] (2) Use poll to monitor the array created in step (1) above. When a new event is detected, perform the next step of svc_getreq_poll processing. Use svc_getreq_poll to create a new connection, add a service request to an existing connection, and destroy abnormal connections that have not completed any work. If the monitoring fails, exit the Sun RPC server.

[0071] On this basis, in order to achieve multi-threading without affecting the basic operation of Sun RPC, the solution of the present invention splits the original one thread listening to the server and all clients into: one thread for processing connection requests; multiple sub-threads for processing business requests. Further, according to the mechanism of Socket, the event received by the RPC server file descriptor is a new connection request, so that the thread listening to the RPC server event can create a sub-thread for each new connection for business processing.

[0072] Compared with the existing solutions, here we innovatively split the original one-thread listening server and all clients to implement a multi-threaded RPC server, effectively overcoming the problems existing in the existing technology.

[0073] Based on the functional differences, the thread of the listening RPC server is set as the management thread or the main thread, and the thread used only for business processing is set as the child thread or the business thread.

[0074] At the same time, the management thread (i.e., main thread) and the service thread (i.e., child thread) set up, both types of threads will perform the basic process of the svc_run() function, thereby realizing the basic functions of Sun RPC without affecting it. Furthermore, the management thread set up can monitor one or more TCP or UDP servers, while the service thread can only monitor one client to complete its service processing.

[0075] According to the functional characteristics of the management thread and business thread set above, this solution needs to distinguish which is the server information and which is the new connection client information from the svc_pollfd record information of Sun RPC, so as to coordinate the management thread and the business thread.

[0076] Since the TCP or UDP server is created before the svc_run() function is started, and the svc_run() function is mainly responsible for monitoring; therefore, before the svc_run() function monitors, the svc_pollfd information of Sun RPC only contains relevant information about the server. Based on this, this solution first targets the client information in the svc_pollfd array of Sun RPC, and recognizes the information of the newly connected client from the svc_pollfd array by judging whether a child thread has been created for it.

[0077] The solution of the present invention improves the svc_getreq_poll() function of the next step of Sun RPC accordingly according to the difference in processing work between the set management thread (ie main thread) and the service thread (ie child thread).

[0078] Specifically, the scheme of the present invention sets the parameters of the svc_getreq_poll() function according to the working characteristics of the management thread and the service thread, so as to determine the way to perform the svc_getreq_poll() function of the next step of Sun RPC.

[0079] For example, the input and output parameters of the management thread are the arrays recording the file descriptors and events of all RPC servers and the number of monitored events;

[0080] For the business thread, since it only performs business processing and no connection request operation in the further processing inside Sun RPC, it will not affect the global array of Sun RPC recording all file descriptors and events. Therefore, the input parameters of the svc_getreq_poll() function here are set to the file descriptor of a single client, the events to be monitored, the array of event information returned, and the number of events monitored.

[0081] Based on the above setting scheme, the scheme of the present invention realizes the business processing of a single connection by monitoring the connection request of the server and creating a child thread for it, thereby being able to process multiple connection requests simultaneously without affecting the basic operation of Sun RPC.

[0082] The following is a detailed description of the working process of the multi-threaded server based on Sun RPC.

[0083] See also Figure 1 , which describes the management thread workflow of this multi-threaded server based on Sun RPC.

[0084] Based on the diagram, the workflow of this management thread is as follows:

[0085] (1) Preparation before the svc_run() function runs: TCP or UDP server starts;

[0086] (2) Get the location of the server's file descriptor and other related information in the svc_pollfd array from Sun RPC;

[0087] (3) Create an array to record the file descriptors and events of the server provided by the svc_pollfd array;

[0088] (4) Monitor the server through the poll() function;

[0089] (5) Determine the monitoring result. When the monitoring error result is -1, execute step (8); when the result is 0, execute step (4); when the result is other, that is, a new connection is detected, execute step (6);

[0090] (6) Pass the array in step (3) and the number of events detected to the svc_getreq_poll() function to perform Sun RPC related operations;

[0091] (7) Obtain information about all connections from the svc_pollfd array. When it is found that the client has no child thread, create a child thread specifically for processing business requests and pass in the location of the client information in the svc_pollfd array. After all client information is checked, execute step (3) to perform a round of monitoring.

[0092] (8) Exit the RPC server and destroy all child threads.

[0093] The management thread workflow formed in this way basically follows the Sun RPC workflow, and innovatively changes the listening object on its basis, changing the original listening server and client file descriptors, events to be listened to and returned event information to only listening to the server, and then adding the step of creating a business thread for the listened client, and destroying the existing business thread when the server exits, thus realizing the management of business threads and the possibility of multiple business threads working simultaneously.

[0094] See also Figure 2 , which describes the workflow of the business threads of this multi-threaded server based on Sun RPC.

[0095] Based on the diagram, the workflow of this business thread is as follows:

[0096] (1) Obtain the file descriptor and event of the corresponding connection from the svc_pollfd array according to the location provided by the management thread, and create an array to record this information;

[0097] (2) Use the poll() function to monitor new connections;

[0098] (3) Determine the monitoring result. When the monitoring error result is -1, execute step (5); when the result is 0, execute step (2); when the result is other, that is, a service request is detected, execute step (4);

[0099] (4) The array in step (1) and the number of service requests detected are handed over to the svc_getreq_poll() function to perform Sun RPC related operations. After the operation is completed, execute step (1) to perform a round of monitoring;

[0100] (5) Exit and destroy this thread.

[0101] Such a business thread workflow basically follows the Sun RPC workflow. On its basis, by changing the monitored object, the original listening server and client file descriptors, the events that need to be monitored and the returned event information are changed to only monitoring a single client. One business thread serves the business request of one client, and multiple business threads are not affected by each other. Multiple business threads enable the server to serve multiple clients at the same time.

[0102] As can be seen from the above, the solution provided by the present invention, by splitting the listening work of Sun RPC into a management thread and multiple business threads, performs different work processing, and effectively realizes the function of the server processing multiple connection requests simultaneously under the premise of complying with the workflow of Sun RPC and not affecting the basic functions of Sun RPC.

[0103] The solution provided by the present invention effectively realizes a multi-threaded RPC server based on Sun RPC, can solve the problem that the Sun RPC single-threaded module framework cannot process multiple requests simultaneously, solves the problem that when a connection request is too long or blocked, it affects other connections, and achieves the goal of serving multiple clients simultaneously.

[0104] The above shows and describes the basic principles, main features and advantages of the present invention. It should be understood by those skilled in the art that the present invention is not limited to the above embodiments, and the above embodiments and descriptions are only for explaining the principles of the present invention. Without departing from the spirit and scope of the present invention, the present invention may have various changes and improvements, which fall within the scope of the present invention to be protected. The scope of protection of the present invention is defined by the attached claims and their equivalents.

Claims

1. A multi-threaded RPC server based on Sun RPC, characterized by: Configured as a management thread that only listens to connection requests, and uses Sun RPC internal methods to add the file descriptor of the new connection, the events to be listened to, and the returned event information to the svc_pollfd array of Sun RPC; A newly connected client is identified from all the client information recorded by svc_pollfd, and a child thread corresponding to the client's service request is created for it. The child thread is configured to process according to the Sun RPC process.

2. The multi-threaded RPC server based on Sun RPC according to claim 1, characterized in that: The multi-threaded RPC server is configured with a management thread unit and a business processing thread unit. The management thread unit is a single thread, configured to monitor the connection request of the server and create a corresponding service thread for each client; The business processing thread unit is a plurality of threads, each of which is configured to process a business request of a client, and resources can be sold automatically after the client disconnects.

3. The multi-threaded RPC server based on Sun RPC according to claim 2, characterized in that: The management thread unit is configured to perform the following operations: (1) Only listen to and record the server file descriptor provided by Sun RPC, the events to be listened, and the array of returned event information in a blocking waiting manner; (2) The server file descriptor provided by Sun RPC, the array of events to be monitored, the event information returned, and the number of monitored events are handed over to Sun RPC for the next step of adding the file descriptor of the new connection, the events to be monitored, and the event information returned to the svc_pollfd array; (3) Create a child thread for the new connection to process the service request, and notify the child thread of the file descriptor of the new connection and the location of the event; (4) When the RPC server is shut down, all child threads that are still connected are destroyed.

4. The multi-threaded RPC server based on Sun RPC according to claim 3, characterized in that: When the management thread unit creates a subthread for processing a service request for a new connection, the management thread unit includes: (1) Filter out newly connected clients from the client information in the svc_pollfd array and create a service thread for them; (2) Separate the newly created business thread.

5. The multi-threaded RPC server based on Sun RPC according to claim 3, characterized in that: The management thread unit monitors the events of the RPC server in a circular manner.

6. The multi-threaded RPC server based on Sun RPC according to claim 5, characterized in that: The management thread unit exits the loop when an error occurs during monitoring, and terminates the RPC server after destroying all child threads.

7. The multi-threaded RPC server based on Sun RPC according to claim 2, characterized in that: The business processing thread unit is configured to be able to perform the following operations: (1) Obtain the file descriptor and event of the new connection, and perform blocking listening on the new connection obtained; (2) After monitoring the service request, it submits the request to Sun RPC for server-side service; (3) When the client disconnects, the corresponding business thread performs self-sale processing.

8. The multi-threaded RPC server based on Sun RPC according to claim 7, characterized in that: The method of obtaining the file descriptor and other information of the new connection is to obtain the file descriptor of the service object, the events to be monitored and the returned events from the svc_pollfd array. The position of the file descriptor and other information of the new connection in the svc_pollfd array is provided by the management thread creating the service thread.

Images