What Is the Current Choice for Doing Rpc in Python

What is the current choice for doing RPC in Python?

XML-RPC is part of the Python standard library:

• Python 2: xmlrpclib and SimpleXMLRPCServer
• Python 3: xmlrpc (both client and server)

Is this RPC protocol?

RPC stands for "Remote Procedure Call". Both of your definitions are doing exactly this, doing remote call of some code with passing (serializing) arguments and returning result (serialized).

The only difference between both definitions is such that 1st definition sends serialized code to remote server, while 2nd uses code already located on server. But still 1st and 2nd are both kinds of RPCs, just differently implemented.

2nd definition is related to API ("Application Programming Interface"), because only 2nd definition has well-defined interface of pre-defined functions with fixed signatures. You "know" what functions are located in API and what params they need. Hence in 2nd case you just reference those remote functions by their names (or anyhow else), instead of sending code itself.

If to choose between two definitions then 2nd is more classical definition of RPC, it is closer to what usually people mean when speaking about RPC.

2nd case also is more secure - because 1st case allows Client to execute arbitrary unchecked/unreliable code on server, which can harm it. While 2nd case allows server to strictly decide what should be run with what types of params.

2nd case is also more informative, because API usually has lots of detailed documentation regarding each function awailable and its properties. In 1st case Client has to have deep understanding of Programming, because arbitrary code is not documented so well anymore as in 2nd API case.

But if you have 2nd case it doesn't mean that you can't have 1st case same time. For example inside 2nd-case API you can just implement function ResultTuple CallAnyCode(FunctionCode, ArgumentsTuple) - this kind of function may allow you to execute arbitrary code remotely. So you have well defined rich API with many function and inside this API there is one function to run arbitrary code (maybe with some higher authenticated rights of Administrator). This is also a common practice on some Servers. In this case 2nd definition will be including 1st definition inside it.

Regarding GRPC ("Google Remote Procedure Call") - it is just one possible implementation of RPC concept provided by Google and used widely inside all Google services as well.

GRPC has well defined strict interface of all functions (API). Every function has a name and format of input Protocol Buffer, basically all parameters described in structured binary form (similar to JSON but serialized in compact binary form). Resulting Protocol Buffer is also strictly described.

So GRPC actually corresponds to your 2nd definition. Because code is located on server and has strictly defined interface. And functions are referenced just by their names, without uploading any code to server.

But this doesn't mean that GRPC can't be used for executing arbitrary code. Still you can create GRPC function Result_ProtoBuf CallAnyCode(Code_plus_Arguments_ProtoBuf) through which you can pass arbitrary serialized code to server and execute it there, if you have enough permissions. In this case GRPC makes a function-wrapper that actually implements 1st definition also.

How can I do synchronous rpc calls

If you're even considering Pyro, check out RPyC first, and re-consider XML-RPC.

Regarding Twisted: try leaving the reactor up instead of stopping it, and just ClientCreator(...).connectTCP(...) each time.

If you self.transport.loseConnection() in your Protocol you won't be leaving open connections.

Bi-directional RPC options for cross-language client/server

On the network when you connect to a server via TCP (or any other similar connection based protocol), when connecting your PC already chooses and listens on a (pseudo/relatively) random port in order to receive the servers answers. So for that matter, as long as the server keeps the connection and both sides keep the connection alive you already have a bi-directional connection. So from a technical, low-level point of view you do not need to initiate a second connection.

Depending on your RPC system it may or may not use TCP and it may or may not feature bi-directional communication (or rather, bi-directional communication initialization).

Now, for thrift, there does not seem to be much documentation there yet (no API reference). But checking the example code it seems to abstract the connection-handling away and use request/response communication only. So in this case, yes, you would have to listen on a defined port client side and tell the server, so the server can initiate a request/response communication.

Go itself provides the rpc package, which is exclusive to go data, so will not help you.

However, it also provides the websocket package. Although initially targeted at webserver to webbrowser communications it is a bi-directional protocol (that’s what it’s about after all) and can be used by any application type. It may not be as efficient size-/bandwidth-wise but it does the job.

I’m not sure about the state of implementation in the go package. The Conn type does have an origin field but the Conn.Dial function example passes http://localhost; I’m not sure whether this is replaced with a remotely-accessible websocket origin. The Handler.ServeHTTP function provides an http.ResponseWriter, which you can probably use to initiate connection as well. At least that’s the first thing I would test.

An alternative, if you are comfortable with using a defined dataformat and handle networking yourself, is protobuf. There is a community project for go bindings to protobuf. You could then handle the TCP connection yourself (connecting to it and sending your data, receiving the data, holding the connection info etc).

As for other alternatives, you may want to check the community packages page and or the community projects page (especially the Go Ajax and go-xmlrpc – both are very rudimentary at this point though).

---

Related Topics