what are the disadvantages of RPC with respect to message passing?

Question

what are the disadvantages of RPC with respect to message passing?

Livia

Answer 1

As a general rule, RPC provides a higher level of abstraction than some other means of interprocess communication. This makes it, perhaps, easier to use than lower level primitives. For this abstraction you may pay some penalty in performance due to marshaling/unmarshaling and may have to deal with added complexity in configuration for simple scenarios.

You might be interested in this thesis (pdf) by Jackie Silcock which discusses differences between message passing, RPC, and distributed shared memory with respect to several different measures of performance and implementation. You can also read one of the papers based on the thesis: Message Passing, Remote Procedure Calls and Distributed Shared Memory as Communication Paradigms for Distributed Systems (pdf)

Berezniki

Link seems to be broken. Do you know where to find the document? – Grum

@norheim.se - the TR seems to be gone, but I tracked down the original thesis and a paper based on it. Hopefully these links will last a bit longer. – Berezniki

Another good comparison - www-scf.usc.edu/~shailesn/csci-555/mp_vs_rpc.html – Nanny

RPC providing a higher level of abstraction?! I'm not really getting how that is. Actually it is quite the opposite, messaging does provide a higher degree of abstraction and low coupling, specially if we are talking about aysnc messaging. RPC is almost all of the time technology dependent (corba, .net remoting) whereas messaging allows for a complete provider abstraction if done right. – Turret

RPC attempts to mask that there is a network involved at all, that is, it attempts to pretend that you're just calling another procedure. I would call that a higher level abstraction in the sense that from the code's perspective it's a simple function call. – Berezniki

@AshishGupta The link is forbidden. – Ocelot

@Marco Absolutely agree with you. Messaging is more abstract. – Antagonist

Answer 2

Are you talking about RPC vs Messaging? As in (typically) asynchronous messaging? If that's what you're talking about, then Messaging tends to be more robust at the cost of complexity and extra infrastructure.

The simplest example is if you have a scenario where you RPC->RPC->RPC, you end up having a call stack that's 3 processes/machines deep. Any one of those processes/machine could fail during processing, and the entire stack unwinds.

If you were messaging, the actual connectivity between the processes is much less. You hand the message off, and you're on your way. Now if one of the processes fail, there's a good chance of it being restarted where it left off, since, typically, the message is still sitting on a queue somewhere waiting for a new process to fetch it. The overall time may be longer, but it's a much more robust system.

Mind it's no panacea, there are a lot of pitfalls with an asynchronous architecture, but this robustness is a prime distinction between RPC and Messaging systems.

Somerset

Anything changed in the last 10 years? :P I just implemented RQM into my stack and have found it indispensable in sanely communicating between micro-services in different environments. Would be interested to hear if your thoughts have changed on the above. – Gulfweed