Foundations of Python Network Programming 978-1-4302-3004-5

CHAPTER 18 ■ RPC
such as Python integers, floats, strings, and tuples. For everything else, it passes across an object name
that lets the remote side reach back into the client to access attributes and invoke methods on those live
objects.
This approach results in quite a bit of network traffic. It can also result in a significant delay if lots of
object operations have to pass back and forth between the client and server before an operation is
complete. Tweaking security properly is also an issue. To give the server permission to call things like
readlines() on the client’s own objects, I chose to make the client connection with a blanket assertion
of allow_public_attrs. But if you are not comfortable giving your server code such complete control,
then you might have to spend a bit of time getting the permissions exactly right for your operations to
work without exposing too much potentially dangerous functionality.
So the technique can be expensive, and security can be tricky if the client and server do not trust
each other. But when you need it, there is really nothing like RPyC for letting Python objects on opposite
sides of a network boundary cooperate with each other. You can even let more than two processes play
the game; check out the RPyC documentation for more details!
The fact that RPyC works successfully like this against vanilla Python functions and objects, without
any requirement that they inherit from or mix in any special network capabilities, is an incredible
testimonial to the power that Python gives us to intercept operations performed on an object and handle
those events in our own way — even by asking a question across the network!
RPC, Web Frameworks, Message Queues
Be willing to explore alternative transmission mechanisms for your work with RPC services. The classes
provided in the Python Standard Library for XML-RPC, for example, are not even used by many Python
programmers who need to speak that protocol. After all, one often deploys an RPC service as part of a
larger web site, and having to run a separate server on a separate port for this on particular kind of web
request can be quite annoying.
There are three useful ways that you can look into moving beyond overly simple example code that
makes it look as though you have to bring up a new web server for every RPC service you want to make
available from a particular site.
First, look into whether you can use the pluggability of WSGI to let you install an RPC service that
you have incorporated into a larger web project that you are deploying. Implementing both your normal
web application and your RPC service as WSGI servers beneath a filter that checks the incoming URL
enables you to allow both services to live at the same hostname and port number. It also lets you take
advantage of the fact that your WSGI web server might already provide threading and scalability at a
level that the RPC service itself does not provide natively.
Putting your RPC service at the bottom of a larger WSGI stack can also give you a way to add
authentication if the RPC service itself lacks such a facility. See Chapter 12 for more information about
WSGI.
Second, instead of using a dedicated RPC library, you may find that your web framework of choice
already knows how to host an XML-RPC, JSON-RPC, or some other flavor of RPC call. This means that
you can declare RPC endpoints with the same ease that your web framework lets you define views or
RESTful resources. Consult your web framework documentation and do a web search for RPC-friendly
third-party plug-ins to see whether this is possible in your case.
Third, you might want to try sending RPC messages over an alternate transport that does a better
job than the protocol’s native transport of routing the calls to servers that are ready to handle them.
Message queues, which are discussed in Chapter 8, are often an excellent vehicle for RPC calls when you
want a whole rack of servers to stay busy sharing the load of incoming requests. If you explore a welldesigned
RPC library like lovely.jsonrpc, you will find that you can define your own transports that
send and receive information through your own mechanism of choice, rather than insisting that HTTP
to a fixed IP address be used.
319