a remote procedure call
/ RPC /
Calling a function on your own machine is easy and familiar: you write result = add(2, 3) and the answer comes back. A remote procedure call is a clever trick that lets you write almost exactly the same thing — result = add(2, 3) — even though add actually runs on a different computer across the network. The whole goal of RPC is to make a network call look and feel like an ordinary local function call, so the programmer can mostly ignore the network.
Here is the mechanism in plain steps. On your side sits a stand-in function called a client stub. When you call add(2, 3), the stub does not do the addition; instead it packs the arguments 2 and 3 into a message (this packing is called marshalling), and sends that message over the network. On the remote machine a matching server stub receives the message, unpacks the arguments, calls the real add, gets 5, marshals 5 into a reply message, and sends it back. Your client stub unpacks 5 and returns it to you as if nothing unusual happened. The stubs are the disguise; they hide all the sockets and message-passing underneath.
Why it matters, and the leak in the abstraction: RPC is the backbone of how services talk to each other across machines. But the disguise is not perfect, and pretending it is gets people into trouble. A local call never just vanishes; a remote one can, because of partial failure. If you call once and get no reply, did it run or not? This forces a choice of failure semantics. At-least-once means the system retries until it hears success — but the operation might then run twice. At-most-once means it never runs twice — but it might run zero times. Exactly-once is what everyone wants and is genuinely hard to guarantee. So an RPC is never quite as innocent as the local call it imitates.
A web app calls getUser(42). It looks like a local call, but the client stub marshals "42", sends it to a user-service on another machine, which looks up user 42 and marshals back their name and email. If the reply is lost, an at-least-once policy resends getUser(42) — harmless because reading is repeatable, but you would NOT want at-least-once on chargeCard(42).
A remote call dressed up as a local one. The disguise leaks under failure, so semantics matter.
The dangerous assumption is that an RPC behaves like a local call. It does not: it can be slow, it can fail, and "no reply" does not mean "did not run". Design idempotent operations (safe to repeat) so at-least-once retries do not cause damage.