9 ms·

Re-Reading Tanenbaum’s Critique of RPC 30 Years Later

77 points by iamwil 5y ago

ngcc_hk 5y ago
I think if the paper can start with the taxtonomy and position the Rpc in it as in the box it would be much better. It is more like he is talking to himself. Too much assumption on the reader. Know rpc, Ipc, Fortran, cobol, … sorry bad writing and need too much effort may I say. What he want to say vs what he said
- alephnan 5y ago
  > sorry bad writing and need too much effort may I say. I’m sorry but his writing was much more intelligible than yours. This writing is an academic critique by an academic. Some context is expected and they’re writing for their audience ( academics and people who have used RPC or have an opinion on them ).
  - commandlinefan 5y ago
    Pretty sure you missed the joke. And I agree with OP that the linked article is pretty impenetrable - he does seem to have something to say, but he doesn't do a good job of saying it. He starts off with what seems to be a very pedantic criticism of the term "RPC" which may be perfectly valid, but he doesn't back it up at all other than to say that procedures exist in programming languages.
  - epgui 5y ago
    Without defending the other commenter, I'll say I agree about the article being poorly written. I'm a slow & careful reader, and I found the poor grammar and confusing constructions difficult to follow.
jacquesm 5y ago
> What would a true remote procedure call in a distributed programming language look like? Have a look at QnX and at the Erlang/OTP framework and virtual machine (called BEAM).
amelius 5y ago
Problem is that RPC doesn't take into account how data is managed, and that you're basically dealing with microservices.
- jacquesm 5y ago
  RPC goes far beyond 'microservices' as a concept unless you use for instance AWS 'Lambda' functions as a reference point. Whoever answers the RPC could be anything, and it could be a very large monolith rather than a microservice.
alephnan 5y ago
I’m mostly lost on the discussion of RPC. This article delves into the historical and more abstract / academic ideas of RPC. By the time I started working in industry, I only know about RPC in practice rather than theory. I’ve never bothered to know the details of RPC, but the main idea ( in practice ) is one computer calling another. Servers have some identifier / address, and the RPC call involves some agreement on the message format. In other words, an API contract + some infrastructure on how to resolve computer names. If it was external, we call it an API over HTTP. Nowadays, we just call the RPC topology as microservices, which is usually an HTTP API, just not on the public internet. I found these bits to be golden: > There is a widespread tendency in computing to adopt more important sounding names for something than is either warranted or is just plain wrong, such as, calling the graph of a network, a topology; calling the chief engineer on a project, the architect; calling a protocol, an API; calling almost anything a new paradigm; etc. There seems to be some deep-seated insecurity in the field that feels a need to inflate the importance of the concepts we work with. > About every decade or so, we have to recycle all of the bad ideas of the previous generation.
- phicoh 5y ago
  It seems to me that in every group of people where a certain concept is often used, that concept will get a short name. You are not going to write out many times 'the chief engineer on a project'. So let's take a mostly unused term, like architect and stick with that. (Read 'The meaning Liff' where Douglas Adams is having fun with the reverse of this) Same thing with RPC, you need to have a term for sending a message to a remote process asking it to execute a particular 'function' and send back the result. At the same time, you don't want write a lot of code in each application to marshall arguments, send a message, wait for the reply, decode the result. So it seems obvious to generate those functions from a description file. And then you have something that looks a bit like a procedure call that is remote. Of course at some point the discussion derails and people start claiming that the RPC is basis of distributed computing. And then other people start writing critiques. That doesn't change the fact that a RPC is a nice concept, as long as you keep in mind what it really is, and what its limitations are.
  - 5y ago
zozbot234 5y ago
[flagged]
gpderetta 5y ago
sort <infile | uniq | wc –l > outfile > [...] This construct uses a push down stack, so that the output of what is inside the angle-brackets is the input to sort It doesn't really invalidate the argument, but unless I'm misunderstanding their statement, I think the author might have misparsed the above.
- gonzus 5y ago
  I am thankful to you for highlighting this part of the long paper. That completely wrong assertion (the input to sort is infile, nothing more, nothing less) casts the rest of the content in doubt (at least it does to me).
  - GeorgeTirebiter 5y ago
    Wait, you're saying that the author of several textbooks on OSs and author of MINIX is, somehow, not trustworthy due to one perhaps inaccurate interpretation? Harsh. ;-)
    - Jtsummers 5y ago
      Tanenbaum did not make the inaccurate interpretation of the: sort < infile | uniq | wc -l > outfile line. John Day, the author of the linked article, was the one who misunderstood it.
- TFortunato 5y ago
  FWIW, in Tanenbaum's original paper (which the author is reading), the correct meaning of the example is given quite plainly: "consider a simple UNIX pipeline: sort <infile | uniq | wc -l >outfile that sorts infile, an ASCII file with one word per line, strips out the duplicates, and prints the word count on outfile." So yes, it does seem the author did missed at least that part. Not sure about the rest of their arguments, but at this point, I'd say it's easy enough to find the original paper, which does seem quite readable. https://www.cs.vu.nl/~ast/Publications/Papers/euteco-1988.pdf https://www.cs.vu.nl/~ast/Publications/Papers/euteco-1988.pd...
- 5y ago
TFortunato 5y ago
Tanenbaum's original critique, which is quite readable, for reference. https://www.cs.vu.nl/~ast/Publications/Papers/euteco-1988.pdf https://www.cs.vu.nl/~ast/Publications/Papers/euteco-1988.pd...
NovemberWhiskey 5y ago
From my point of view, Tannenbaum's critique is basically that RPC is an exceedingly leaky abstraction. I don't think very much has changed in the state of the art to address that point: you still need to understand that your arguments will need to be marshaled (which restricts what types make sense in languages that support pointers, references etc), you still need to deal with exceptions that result from the RPC mechanism as opposed to business logic, you still need to worry about whether those exceptions mean the procedure completed, or not, or when it might've failed, which forces you to structure the code for idempotency and so on.
moomin 5y ago
I find it interesting that one of Tanenbaum’s criticisms: that they needed to be part of the language, has indeed been addressed. Pretty much every language now has Promise-like semantics that do, indeed, allow you to use a network call in a similar manner to a regular procedure call. But we had to change the semantics of the average programming language to do it. His take that it needed to be part of the OS seems to have proved incorrect. TCP and UDP are definitely part of the OS, but HTTP sits in the user layer without people blinking an eye.
JonChesterfield 5y ago
It's worth mentioning that the primary hazard, that networks fail and this makes a mess of function types, does not necessarily apply on shared memory systems. Specifically when 'remote' means a CPU in the same address space, communicating over a reliable medium (if pcie fails, so does the nldey, which ~= perfectly reliable), then pointers can be passed around without problem and the function call can look and behave exactly as if it was running on the local CPU.
omginternets 5y ago
>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. This is precisely where I feel like there has been substantial progress. RPC frameworks like Cap'n Proto do an excellent job of providing network-aware APIs that give you precise control over network IO.

77 points by iamwil 5y ago

I think if the paper can start with the taxtonomy and position the Rpc in it as in the box it would be much better. It is more like he is talking to himself. Too much assumption on the reader. Know rpc, Ipc, Fortran, cobol, … sorry bad writing and need too much effort may I say. What he want to say vs what he said

alephnan 5y ago
> sorry bad writing and need too much effort may I say. I’m sorry but his writing was much more intelligible than yours. This writing is an academic critique by an academic. Some context is expected and they’re writing for their audience ( academics and people who have used RPC or have an opinion on them ).
- commandlinefan 5y ago
  Pretty sure you missed the joke. And I agree with OP that the linked article is pretty impenetrable - he does seem to have something to say, but he doesn't do a good job of saying it. He starts off with what seems to be a very pedantic criticism of the term "RPC" which may be perfectly valid, but he doesn't back it up at all other than to say that procedures exist in programming languages.
- epgui 5y ago
  Without defending the other commenter, I'll say I agree about the article being poorly written. I'm a slow & careful reader, and I found the poor grammar and confusing constructions difficult to follow.

jacquesm 5y ago

> What would a true remote procedure call in a distributed programming language look like? Have a look at QnX and at the Erlang/OTP framework and virtual machine (called BEAM).

amelius 5y ago

Problem is that RPC doesn't take into account how data is managed, and that you're basically dealing with microservices.

jacquesm 5y ago
RPC goes far beyond 'microservices' as a concept unless you use for instance AWS 'Lambda' functions as a reference point. Whoever answers the RPC could be anything, and it could be a very large monolith rather than a microservice.

alephnan 5y ago

I’m mostly lost on the discussion of RPC. This article delves into the historical and more abstract / academic ideas of RPC. By the time I started working in industry, I only know about RPC in practice rather than theory. I’ve never bothered to know the details of RPC, but the main idea ( in practice ) is one computer calling another. Servers have some identifier / address, and the RPC call involves some agreement on the message format. In other words, an API contract + some infrastructure on how to resolve computer names. If it was external, we call it an API over HTTP. Nowadays, we just call the RPC topology as microservices, which is usually an HTTP API, just not on the public internet. I found these bits to be golden: > There is a widespread tendency in computing to adopt more important sounding names for something than is either warranted or is just plain wrong, such as, calling the graph of a network, a topology; calling the chief engineer on a project, the architect; calling a protocol, an API; calling almost anything a new paradigm; etc. There seems to be some deep-seated insecurity in the field that feels a need to inflate the importance of the concepts we work with. > About every decade or so, we have to recycle all of the bad ideas of the previous generation.

phicoh 5y ago
It seems to me that in every group of people where a certain concept is often used, that concept will get a short name. You are not going to write out many times 'the chief engineer on a project'. So let's take a mostly unused term, like architect and stick with that. (Read 'The meaning Liff' where Douglas Adams is having fun with the reverse of this) Same thing with RPC, you need to have a term for sending a message to a remote process asking it to execute a particular 'function' and send back the result. At the same time, you don't want write a lot of code in each application to marshall arguments, send a message, wait for the reply, decode the result. So it seems obvious to generate those functions from a description file. And then you have something that looks a bit like a procedure call that is remote. Of course at some point the discussion derails and people start claiming that the RPC is basis of distributed computing. And then other people start writing critiques. That doesn't change the fact that a RPC is a nice concept, as long as you keep in mind what it really is, and what its limitations are.
- 5y ago

zozbot234 5y ago

[flagged]

gpderetta 5y ago

sort <infile | uniq | wc –l > outfile > [...] This construct uses a push down stack, so that the output of what is inside the angle-brackets is the input to sort It doesn't really invalidate the argument, but unless I'm misunderstanding their statement, I think the author might have misparsed the above.

gonzus 5y ago
I am thankful to you for highlighting this part of the long paper. That completely wrong assertion (the input to sort is infile, nothing more, nothing less) casts the rest of the content in doubt (at least it does to me).
- GeorgeTirebiter 5y ago
  Wait, you're saying that the author of several textbooks on OSs and author of MINIX is, somehow, not trustworthy due to one perhaps inaccurate interpretation? Harsh. ;-)
  - Jtsummers 5y ago
    Tanenbaum did not make the inaccurate interpretation of the: sort < infile | uniq | wc -l > outfile line. John Day, the author of the linked article, was the one who misunderstood it.
TFortunato 5y ago
FWIW, in Tanenbaum's original paper (which the author is reading), the correct meaning of the example is given quite plainly: "consider a simple UNIX pipeline: sort <infile | uniq | wc -l >outfile that sorts infile, an ASCII file with one word per line, strips out the duplicates, and prints the word count on outfile." So yes, it does seem the author did missed at least that part. Not sure about the rest of their arguments, but at this point, I'd say it's easy enough to find the original paper, which does seem quite readable. https://www.cs.vu.nl/~ast/Publications/Papers/euteco-1988.pdf https://www.cs.vu.nl/~ast/Publications/Papers/euteco-1988.pd...
5y ago

TFortunato 5y ago

Tanenbaum's original critique, which is quite readable, for reference. https://www.cs.vu.nl/~ast/Publications/Papers/euteco-1988.pdf https://www.cs.vu.nl/~ast/Publications/Papers/euteco-1988.pd...

NovemberWhiskey 5y ago

From my point of view, Tannenbaum's critique is basically that RPC is an exceedingly leaky abstraction. I don't think very much has changed in the state of the art to address that point: you still need to understand that your arguments will need to be marshaled (which restricts what types make sense in languages that support pointers, references etc), you still need to deal with exceptions that result from the RPC mechanism as opposed to business logic, you still need to worry about whether those exceptions mean the procedure completed, or not, or when it might've failed, which forces you to structure the code for idempotency and so on.

moomin 5y ago

I find it interesting that one of Tanenbaum’s criticisms: that they needed to be part of the language, has indeed been addressed. Pretty much every language now has Promise-like semantics that do, indeed, allow you to use a network call in a similar manner to a regular procedure call. But we had to change the semantics of the average programming language to do it. His take that it needed to be part of the OS seems to have proved incorrect. TCP and UDP are definitely part of the OS, but HTTP sits in the user layer without people blinking an eye.

JonChesterfield 5y ago

It's worth mentioning that the primary hazard, that networks fail and this makes a mess of function types, does not necessarily apply on shared memory systems. Specifically when 'remote' means a CPU in the same address space, communicating over a reliable medium (if pcie fails, so does the nldey, which ~= perfectly reliable), then pointers can be passed around without problem and the function call can look and behave exactly as if it was running on the local CPU.

omginternets 5y ago

>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. This is precisely where I feel like there has been substantial progress. RPC frameworks like Cap'n Proto do an excellent job of providing network-aware APIs that give you precise control over network IO.