RPyC - Transparent, Symmetric Distributed Computing¶
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.
For an introductory reading, 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 (awk, sed, grep, ...)
- 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 ctypes module (or open the /dev file directly).
- Monkey-patch local code or remote code. For instance, using monkey-patching you can cross network boundaries by replacing the socket module of one program with a remote one. Another example could be replacing the os module 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)