3 ms·

Really interesting article. Wish there was a discussion of performance for various RPCs from the past.

by irq-1 4y ago

cryptonector 4y ago
There's so many... Apollo Domain's. ONC RPC. DCE RPC (and MSFT RPC, which derives from DCE RPC). SOAP. LustreRPC. And who knows how many others. The biggest problem with RPC in general is that historically it was synchronous because that's what was easy to implement in the 80s. Fix that and an RPC sucks only as much as the encoding system it uses. But RPC == remote procedure call, and that causes people to instantly think "synchronous", and that is a kiss of death.
- cjsplat 4y ago
  Well of course once you say "procedure call", people think synchronous. For the sender, asynchronous RPC is just a convenient marshalling and return interface for the sender. It is pretty clunky for the A-RPC caller to create an illusion in the code of the RPC being "just like" a local procedure call. For the called procedure an Async RPC can look just like a local sync procedure call, except for that whole address space thing. I don't think that sync RPC was popular because it was easy to implement. I think it was popular because it was easy to code to. Multi-threaded coding is easy to get wrong, and was poorly understood at the time.
  - cryptonector 4y ago
    > I think it was popular because it was easy to code to. That's not that unlike it being easy to implement. > Multi-threaded coding is easy to get wrong, [...] Yeah, but the better design is async/await and so on, not threading, but that stuff was not very popular in the 80s. The approach to concurrency in the 80s was heavy on context switching because that's what was inherited from the 70s. It feels like the thinking was along the lines of "during the time you're waiting for a response some other process will run, and since we're used to heavy latency, who cares!", but that became less and less tenable. There's a reason all the distributed operating system research of the 80s died except for filesystems -- with filesystems you can consciously avoid hot ping pong by just not accessing shared resources concurrently, while the filesystem itself remains super useful.
rswail 4y ago
RPC in general failed for two reasons: 1. Synchronous in an async environment 2. Brittle client/server coupling of RPC definitions HTTP is a remote procedure call, it's request/response. Each request/response pair is independent and asynchronous. The difference between HTTP and a more "specified" RPC is that the body of the request and the body of the response are defined "out of band" and are flexible enough to allow for the client and the server to evolve independently. I could make HTTP look like ONC-RPC by using XDR to martial the arguments in the request/response body and map the actual procedure name to the URL. The MIME type "application/protobuf" exists to do the same using protobufs. So does "applicaton/vnd.google.protobuf". HTTP was built using TCP as the reliable connection layer over the IP packet protocol but QUIC replaces that using UDP over IP to remove the problems that a connection based/reliable protcol like TCP causes. Really not sure what a new protocol would provide other than shuffling the boundaries again.

Really interesting article. Wish there was a discussion of performance for various RPCs from the past.

by irq-1 4y ago

Really interesting article. Wish there was a discussion of performance for various RPCs from the past.

There's so many... Apollo Domain's. ONC RPC. DCE RPC (and MSFT RPC, which derives from DCE RPC). SOAP. LustreRPC. And who knows how many others. The biggest problem with RPC in general is that historically it was synchronous because that's what was easy to implement in the 80s. Fix that and an RPC sucks only as much as the encoding system it uses. But RPC == remote procedure call, and that causes people to instantly think "synchronous", and that is a kiss of death.

cjsplat 4y ago
Well of course once you say "procedure call", people think synchronous. For the sender, asynchronous RPC is just a convenient marshalling and return interface for the sender. It is pretty clunky for the A-RPC caller to create an illusion in the code of the RPC being "just like" a local procedure call. For the called procedure an Async RPC can look just like a local sync procedure call, except for that whole address space thing. I don't think that sync RPC was popular because it was easy to implement. I think it was popular because it was easy to code to. Multi-threaded coding is easy to get wrong, and was poorly understood at the time.
- cryptonector 4y ago
  > I think it was popular because it was easy to code to. That's not that unlike it being easy to implement. > Multi-threaded coding is easy to get wrong, [...] Yeah, but the better design is async/await and so on, not threading, but that stuff was not very popular in the 80s. The approach to concurrency in the 80s was heavy on context switching because that's what was inherited from the 70s. It feels like the thinking was along the lines of "during the time you're waiting for a response some other process will run, and since we're used to heavy latency, who cares!", but that became less and less tenable. There's a reason all the distributed operating system research of the 80s died except for filesystems -- with filesystems you can consciously avoid hot ping pong by just not accessing shared resources concurrently, while the filesystem itself remains super useful.

rswail 4y ago

RPC in general failed for two reasons: 1. Synchronous in an async environment 2. Brittle client/server coupling of RPC definitions HTTP is a remote procedure call, it's request/response. Each request/response pair is independent and asynchronous. The difference between HTTP and a more "specified" RPC is that the body of the request and the body of the response are defined "out of band" and are flexible enough to allow for the client and the server to evolve independently. I could make HTTP look like ONC-RPC by using XDR to martial the arguments in the request/response body and map the actual procedure name to the URL. The MIME type "application/protobuf" exists to do the same using protobufs. So does "applicaton/vnd.google.protobuf". HTTP was built using TCP as the reliable connection layer over the IP packet protocol but QUIC replaces that using UDP over IP to remove the problems that a connection based/reliable protcol like TCP causes. Really not sure what a new protocol would provide other than shuffling the boundaries again.