Using Waldo et al.'s 1994 critique of RPC location transparency, what goes wrong when a team designs local objects and decides later which become remote?

## The plan being critiqued **Location transparency** is the promise that a caller need not know whether an object is local or remote: the stub makes both look the same. Taken to its end, it suggests a development plan - write the system as ordinary local objects, get it working, then decide which objects run on which machines, letting generated stubs absorb the difference. Waldo et al.'s *A Note on Distributed Computing* (1994) argues that this plan fails. Its abstract states the thesis: objects that interact in a distributed system must be treated in ways intrinsically different from objects in a single address space, because programmers must be aware of latency, work with a different model of memory access, and take concurrency and partial failure into account; systems that paper over the distinction fail basic requirements of robustness and reliability. ## The four differences | Difference | Local call | Remote call | What it forces in the design | |---|---|---|---| | **Latency** | Nanoseconds to microseconds | Orders of magnitude slower, plus network variance | Coarse-grained operations; fewer round trips | | **Memory access** | Shared address space; references and side effects work | No shared memory; arguments are copied | Explicit results instead of mutated arguments | | **Partial failure** | The call returns or the whole process dies | Callee or network can fail while the caller lives | Failure outcomes in the interface; timeouts | | **Concurrency** | The program controls its own threads | Independent clients call at once, with no common control | The remote object handles concurrent callers itself | RFC 5531, writing about ONC RPC, lists overlapping differences in plain terms: failures of the remote server or network must be handled, the server has no access to the client's address space, and remote procedures usually run "one or more orders of magnitude slower" than local ones. ## Why a better stub does not fix it - **Latency** can be reduced by faster networks and placement, and its cost hidden by caching - but an interface that makes a round trip per getter stays slow by design. - **Memory access** can be tamed by a programming model that never passes raw references, making copies the norm everywhere. - **Partial failure** cannot be engineered away. In one process a call either returns or the process is gone; across a network the caller can be alive while the callee, or the link, is not - and often cannot tell which. Mapping that onto an ordinary exception does not tell the caller what to do. - **Concurrency** is equally structural: a remote object is shared by callers that do not coordinate with each other. Because the last two differences live in the system, not in the stub, an interface written as if they did not exist has no place to express them. Adding them later changes the interface - and every caller. ## What designing for distribution looks like 1. **Coarse-grained operations** that do a meaningful unit of work per call, returning what the caller needs in one round trip. 2. **Explicit outcomes** in the signature or contract: what errors a call can return, and which calls may safely be repeated. What a timed-out call means for the remote work is its own subject. 3. **Time limits** on every call, so a caller is never parked forever on a silent peer. 4. **Concurrency control** inside the remote object: no assumption that one caller owns it. 5. **Visible remoteness** where it helps - asynchronous or streaming call shapes instead of pretending every call is an instant local one. ## What the critique does not say - It does not say RPC is wrong. Stubs and remote calls remain useful; the claim is that remote interfaces must be designed as remote. - It does not say transparency of **addressing** is wrong. Not caring which host serves a call is different from pretending the call cannot fail. - It does not say local and remote code must share nothing - only that the boundary between them is a design decision made up front, not a deployment detail made later. ## Common confusions - "Latency is the only difference" - it is the most visible, and the most fixable. - "A fast enough network makes remote calls local" - it shrinks latency; partial failure and concurrency remain. - "Turning network errors into exceptions hides partial failure" - it only renames it; the caller still does not know what happened on the other side.