RPyC - Transparent, Symmetric Distributed Computing¶
Version 5.3.1 has been released!
Be sure to read the changelog before upgrading!
Please use the github issues to ask questions report problems. Please do not email me directly
RPyC (pronounced as are-pie-see), or Remote Python Call, is a transparent python library for symmetrical remote procedure calls, clustering and distributed-computing. RPyC makes use of object-proxying, a technique that employs python’s dynamic nature, to overcome the physical boundaries between processes and computers, so that remote objects can be manipulated as if they were local.
Installing RPyC is as easy as
pip install rpyc.
If you’re new to RPyC, be sure to check out the Tutorial. Next, refer to the Documentation and API Reference, as well as the Mailing List.
For an introductory reading (that may or may not be slightly outdated), David Mertz wrote a very thorough Charming Python installment about RPyC, explaining how it’s different from existing alternatives (Pyro, XMLRPC, etc.), what roles it can play, and even show-cases some key features of RPyC (like the security model, remote monkey-patching, or remote resource utilization).
- Transparent - access to remote objects as if they were local; existing code works seamlessly with both local or remote objects.
- Symmetric - the protocol itself is completely symmetric, meaning both client and server can serve requests. This allows, among other things, for the server to invoke callbacks on the client side.
- Synchronous and asynchronous operation
- Platform Agnostic - 32/64 bit, little/big endian, Windows/Linux/Solaris/Mac… access objects across different architectures.
- Low Overhead - RpyC takes an all-in-one approach, using a compact binary protocol, and requiring no complex setup (name servers, HTTP, URL-mapping, etc.)
- Secure - employs a Capability based security model; intergrates easily with SSH
- Zero-Deploy Enabled – Read more about Zero-Deploy RPyC
- Integrates with TLS/SSL, SSH and inetd.
- Excels in testing environments – run your tests from a central machine offering a convenient development environment, while the actual operations take place on remote ones.
- Control/administer multiple hardware or software platforms from a central point: any machine
that runs Python is at your hand! No need to master multiple shell-script languages (BASH,
Windows batch files, etc.) and use awkward tools (
- Access remote hardware resources transparently. For instance, suppose you have some proprietary
electronic testing equipment that comes with drivers only for HPUX, but no one wants to
actually use HPUX… just connect to the machine and use the remote
ctypesmodule (or open the
- Monkey-patch local code or remote code.
For instance, using monkey-patching you can cross network boundaries by replacing the
socketmodule of one program with a remote one. Another example could be replacing the
osmodule of your program with a remote module, causing
os.system(for instance) to run remotely.
- Distributing workload among multiple machines with ease
- Implement remote services (like WSDL or RMI) quickly and concisely (without the overhead and limitations of these technologies)