3 ms·

Just What We Need: Another RPC Package

8 points by prakash 18y ago

aggieben 18y ago
Topic story was not all that interesting (Cisco re-invents the wheel!), but it led me to Thrift (http://developers.facebook.com/thrift/ http://developers.facebook.com/thrift/) and Ice (http://zeroc.com/index.html http://zeroc.com/index.html), which I didn't know about.
LogicHoleFlaw 18y ago
CORBA, SOAP, JSON, REST... do we really need a new RPC stack? I don't see any new value here. In the end you can't hide the network.
- ajross 18y ago
  JSON isn't an RPC protocol, it's a data format. And REST is a web architecture, it lives at a higher level (and on top of HTTP, which is not an RPC protocol). RPC architectures are things likes Sun-RPC, CORBA, SOAP, XML-RPC, DCOM/COM+, etc... They model the network as a bunch of objects on which you can call methods/functions from within an existing programming environment. Which sounds like a nifty idea until you try it and discovers that it sucks (see above rant).
  - LogicHoleFlaw 18y ago
    Pardon me, I'm just bitter today after wrangling with unruly WSDLs.
ajross 18y ago
After three decades of minimal-to-mixed success, you would really think people would have figured out by now that RPC is a fundamentally flawed metaphor. It's not pipelineable, which means that it's always going to be slow. It's a deadlock waiting to happen. And it's obscure: it takes the simple notion of calling a method (say, to extract a single field) and hides from the programmer the fact that this simple object might live on another side of a content. Just a disaster. Without exception, every successful network protocol has a query/response structure. Even things that are "technically" based on an "RPC" protocol (NFS) have evolved in this direction for performance and simplicity. Take a look at the code for an NFS stack and see if you can see the "procedure calls" to the remote server. They aren't there.
ComputerGuru 18y ago
I see a lot of RPC-bashing going on here... I actually use it (typically via higher-level wrappers in Java or C#), and it's OK.... but what do you guys recommend as an alternative?
- ajross 18y ago
  Alternative for what problem? The issue is that RPC tends to fool people into spamming the network. Where a traditional database query would issue one request and get back a thousand rows of eight columns in a pipelined stream, a (dumb, but entirely plausible) RPC architecture might end up iterating over a thousand remote objects, calling an accessor method for each field, and making thousands of synchronous round trips to the server to accomplish what the SQL query did in just one.
huhtenberg 18y ago
Given Cisco's history of designing and standardizing protocols, I'll consider their RPC protocol over SOAP at any time (even having a cursory knowledge of it). The problem with SOAP is not that it's bloated or that doesn't allow for efficient parsing or whatever the flaw du jour is. The problem is that it's was created, promoted and embraced by people ignorant of established protocol design practices. If they wanted interoperability, there was an ASN.1 in DER or PER encoding readily available. If they wanted forward compatibility - why not use trivial TLV encoding ? And why the hell would anyone want to use text-based protocol for passing binary data around ? "Easier to troubleshoot" they say. Huh ?! ARE YOU NUTS ? Why not render the data into a .png then and exchange those instead ? </rant> So, I really hope Cisco does standardize their protocol. RPC may be a flawed approach to begin with, but at the very least there'll be a decent protocol to utilize this "flawed" technology.

8 points by prakash 18y ago

Topic story was not all that interesting (Cisco re-invents the wheel!), but it led me to Thrift (http://developers.facebook.com/thrift/ http://developers.facebook.com/thrift/) and Ice (http://zeroc.com/index.html http://zeroc.com/index.html), which I didn't know about.

LogicHoleFlaw 18y ago

CORBA, SOAP, JSON, REST... do we really need a new RPC stack? I don't see any new value here. In the end you can't hide the network.

ajross 18y ago
JSON isn't an RPC protocol, it's a data format. And REST is a web architecture, it lives at a higher level (and on top of HTTP, which is not an RPC protocol). RPC architectures are things likes Sun-RPC, CORBA, SOAP, XML-RPC, DCOM/COM+, etc... They model the network as a bunch of objects on which you can call methods/functions from within an existing programming environment. Which sounds like a nifty idea until you try it and discovers that it sucks (see above rant).
- LogicHoleFlaw 18y ago
  Pardon me, I'm just bitter today after wrangling with unruly WSDLs.

ajross 18y ago

After three decades of minimal-to-mixed success, you would really think people would have figured out by now that RPC is a fundamentally flawed metaphor. It's not pipelineable, which means that it's always going to be slow. It's a deadlock waiting to happen. And it's obscure: it takes the simple notion of calling a method (say, to extract a single field) and hides from the programmer the fact that this simple object might live on another side of a content. Just a disaster. Without exception, every successful network protocol has a query/response structure. Even things that are "technically" based on an "RPC" protocol (NFS) have evolved in this direction for performance and simplicity. Take a look at the code for an NFS stack and see if you can see the "procedure calls" to the remote server. They aren't there.

ComputerGuru 18y ago

I see a lot of RPC-bashing going on here... I actually use it (typically via higher-level wrappers in Java or C#), and it's OK.... but what do you guys recommend as an alternative?

ajross 18y ago
Alternative for what problem? The issue is that RPC tends to fool people into spamming the network. Where a traditional database query would issue one request and get back a thousand rows of eight columns in a pipelined stream, a (dumb, but entirely plausible) RPC architecture might end up iterating over a thousand remote objects, calling an accessor method for each field, and making thousands of synchronous round trips to the server to accomplish what the SQL query did in just one.

huhtenberg 18y ago

Given Cisco's history of designing and standardizing protocols, I'll consider their RPC protocol over SOAP at any time (even having a cursory knowledge of it). The problem with SOAP is not that it's bloated or that doesn't allow for efficient parsing or whatever the flaw du jour is. The problem is that it's was created, promoted and embraced by people ignorant of established protocol design practices. If they wanted interoperability, there was an ASN.1 in DER or PER encoding readily available. If they wanted forward compatibility - why not use trivial TLV encoding ? And why the hell would anyone want to use text-based protocol for passing binary data around ? "Easier to troubleshoot" they say. Huh ?! ARE YOU NUTS ? Why not render the data into a .png then and exchange those instead ? </rant> So, I really hope Cisco does standardize their protocol. RPC may be a flawed approach to begin with, but at the very least there'll be a decent protocol to utilize this "flawed" technology.