Chapter 18 ■ rpC347your program should retry a failed call, you might want to try using something like the exponential back-off algorithm
for UDP discussed in Chapter 3. This approach lets you avoid hammering an overloaded service and making the
situation worse.
Finally, be careful about working around the loss of exception detail across the network. Unless you are using a
Python-aware RPC mechanism, you will probably find that what would normally be a familiar and friendly KeyError
or ValueError on the remote side becomes some sort of RPC-specific error whose text or numeric error code you have
to inspect in order to have any chance of telling what happened.
Summary
RPC lets you write what look like normal Python function calls, which actually reach across the network and call a
function on another server. They do this by serializing the parameters so they can be transmitted; they then do the
same with the return value that is sent back.
All RPC mechanisms work pretty much the same way: you set up a network connection and then make calls on
the proxy object that you are given in order to invoke code on the remote end. The old XML-RPC protocol is natively
supported in the Python Standard Library, while good third-party libraries exist for the sleeker and more modern
JSON-RPC.
Both of these mechanisms allow only a handful of data types to pass between the client and server. If you want a
much more complete array of the Python data types available, then you should look at the Pyro system, which can link
Python programs across the network with extensive support for native Python types. The RPyC system is even more
extensive, and it allows actual objects to be passed between systems in such a way that method calls on those objects
are forwarded to the system on which the object actually lives.
Looking back over the material in this book, you will be tempted to begin seeing every single chapter as
somehow about RPC; that is, about the exchange of information between a client program and a server, mediated by
an agreement about what a request will involve and how a response will look. Now that you have learned RPC, you
have seen this exchange at its most general, designed not to support any one specific action but to support arbitrary
communication. When implementing new services—and especially when you’re tempted to use RPC—always
consider whether your problem really needs the flexibility of RPC or whether the transaction between your client and
server might be reduced to one of the simpler, limited-purpose protocols from earlier in this book. If you select the
right protocol for each problem you face, incurring no more complexity than is necessary, you will be well rewarded
by networked systems that are simple, reliable, and easy to maintain.