Prologue, this is a popular series about the concept of RPC, mainly through step-by-step adjustment, refining a relatively complete RPC framework.
RPC (remote Procedure call Protocol)-Remoting protocol, based on the C/S model. There is a good article on the Internet, you can go to understand the relevant concepts in simple RPC
Here, directly using a sketch of the author above
There are 4 core elements to be summed up.
the transmission of RPC data . Like the rpcconnector,rpcchannel above. They are mainly responsible for data transmission of this piece, the specific client-server connection is not a socket connection, is the original TCP connection or use HTTP, the RPC protocol itself does not make any provision. so our task is to abstract such a transport layer. RPC message. such as the RpcProtocol above, and the Encode,decode method. Because RPC is a remote call, there is no way to direct function calls, so you must use a special set of protocols to represent the invocation and the result of the call. In addition, because the actual application is basically a cross machine connection, it is not possible to pass the memory variables directly, that is, you also need to encode the message into something such as a string that can be transferred across the device. There are many encapsulation protocols for specific RPC messages, often based on Xml,json encapsulation. so our task is to abstract such a layer of protocol. RPC Service registration. as above callee-->export. What calls are specifically supported by the server, and how to invoke the actual method that needs to be executed after receiving the RPC request from the client, which is also a complete RPC framework to consider. Some of the more advanced frameworks, all of which can be serviced automatically, are now the mainstream RPC framework, which also supports the definition of remote interfaces through IDL (Interface definition Language) to enable Cross-language RPC. then our task is to abstract an RPC service registration mechanism . RPC Message processing . Like the rpcinvoker above. This is actually not related to RPC itself, it is generally considered to support asynchronous/synchronous calls . This part, probably I will also make some notes, but not the focus of this series. The RPC framework, farmers will use Python as a development language, why, but also a bit embarrassed: less code, easy to explain (lazy is the nature of the code workers). The initial idea is that the entire framework starts with the original normal call, and then evolves in a step-by-step way, finally generating a complete RPC framework. I hope that in this process, you will be able to bring you more in-depth RPC entry knowledge, as well as the knowledge of code modification. That's a little high, huh?