A Critique of the Remote Procedure Call Paradigm (1988) [pdf]

https://www.cs.vu.nl/~ast/Publications/Papers/euteco-1988.pdf

by culturedsystems • 4 years ago

19 9 4 years ago

cs.vu.nl

Jtsummers2• 4 years ago

Only past discussion with comments:

https://news.ycombinator.com/item?id=10029202 - Aug 9, 2015 (13 comments)

RedShift12• 4 years ago

The format these scientific PDFs use is really annoying to read on mobile, the text is too small for me to read comfortably. Any tips or maybe an app that can make this better?

Jtsummers2• 4 years ago

https://medium.com/@ilegacy/a-critique-of-the-remote-procedu...

On Medium, but someone took the time to make a blog version of it. Seems to be the correct text (didn't read it all side by side to make a full comparison, just checked a few spots).

RedShift12• 4 years ago

Awesome, thanks!

amw-zero• 4 years ago

I read them in landscape, it’s mostly readable then.

omaranto• 4 years ago

Any tips

Put your phone in landscape orientation, pinch-zoom until the text takes up the entire width of the screen.

JonChesterfield• 4 years ago

A brief discussion of a discussion of the paper is at https://news.ycombinator.com/item?id=30812746

lioeters• 4 years ago

By RPC, they mean remote procedure calls that "look exactly like local ones", indistinguishable (or undistinguished).

Our criticism of RPC concerns the advisability of its use as a general communication model, for arbitrary applications.
..Imagine that two programmers are working on a project. Programmer 1 is writing the main program. Programmer 2 is writing a collection of procedures to be called by the main program. The subject of RPC has never been mentioned and both programmers assume that all their code will be compiled and linked together into a single executable binary program and run on a free-standing computer, not connected to any networks.
At the very last minute, after all the code has been thoroughly tested, debugged, and documented and both programmers have quit their jobs and left the country, the project management is forced by unexpected, external circumstances to run the program on a distributed system. The main program must run on one computer, and each procedure must run on a different computer.
It is our contention that a large number of things may now go wrong due to the fact that RPC tries to make remote procedure calls look exactly like local ones, but is unable to do it perfectly. Many of the problems can be solved by modifying the code is various ways, but then the transparency is lost.

That's quite different from what I picture when I hear the term RPC, as a style of API design like gRPC, where it's clear and obvious that the calls are remotely made, unlike local functions.

gRPC: A high performance, open source universal RPC framework - https://grpc.io/

But then again, Wikipedia's definition also mentions RPC is coded as if it were a local call.

In distributed computing, a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in a different address space (commonly on another computer on a shared network), which is coded as if it were a normal (local) procedure call, without the programmer explicitly coding the details for the remote interaction.

https://en.wikipedia.org/wiki/Remote_procedure_call

pjmlp• 4 years ago

Most languages have gRPC SDKs that create the same kind of high level bindings, it is only yet another transport mechanism to do RPC.

A Critique of the Remote Procedure Call Paradigm (1988) [pdf]

Related Stories