The disadvantages of RPC technology include the fact that there is no uniform standard for RPC calls. The various – mostly company-specific – implementations (e.g. ONC-RPC from Sun) are usually not compatible with each other. In addition, the transfer and communication levels of RPC-based systems entail certain speed reductions, which is not the case with purely local procedure calls. Since the client and server use different execution environments for their respective routines, the use of resources (e.g. files) is also more complex. RPC systems are therefore not so well suited for transferring large amounts of data.
By dividing it up into different processing instances, the error rate is increased. Messages can get lost in communication (network errors, failure of a node in the network), and delays and interruptions may arise. Timing issues, redundant double executions (e.g. of process calls), or undesirable asynchronies in machine communication are among the resulting complications. With synchronous RPC, a server problem (e.g. a crash) can affect the client if the calling process waits in vain for the return value. On the other hand, the server is slowed down if the client’s response is delayed or does not arrive at all. This susceptibility to errors can have a far-reaching impact, particularly in large architectures with a high degree of task distribution.
Due to possible sources of error, special RPC error semantics must also be taken into account, which makes programming relatively complex. Programmers and system developers have to deal with the security aspects that distributed systems and their communication via RPC and UDP/IP or TCP/IP entail (network security, hacking, denial-of-service attacks etc.).