5 ms·

So Google (Protocol Buffers - RPC), Facebook (Thrift - RPC), Twitter (Finagle/Thrift - RPC), GitHub (BERT-RPC), DotCloud (ZeroRPC), Quora (Thrift - RPC) and all

• m0th87 14y ago
  To some degree, it's a fair critique. RPC is a loaded term, because there were far too many implementations that tried to hide the network, which is a recipe for disaster. We were hesitant of going forward with the name ZeroRPC ourselves because of the historical baggage. That said, most of the faults people have placed on RPC have been products of individual implementations and not the concept itself, and there really is much more momentum behind RPC engines than anything else. For my Master's thesis, I implemented a generative communication [1] engine. While I still feel like it's a "beautiful" model, it turns out no one cares. Developers understand RPC calls. Not that many get tuples / tuplespaces / pattern matching and why that can be nice. 1: http://theory.sci.univr.it/papers/Isa-orig/Varie/Linda2.pdf http://theory.sci.univr.it/papers/Isa-orig/Varie/Linda2.pdf
  • chubot 14y ago
    The terms are fuzzy, but tuple spaces aren't solving the same problem RPC. That is, you can _use_ RPC to implement tuple spaces. But not the other way around! Message queues are basically the modern tuple spaces, and I'll bet all the companies listed above use message queues too. RPC has its place but it's overused. It's a low level primitive, not a distributed systems architecture. Some people's architecture is basically just RPC spaghetti, with a naive handling of errors. The argument is confused by the fact that you can use an RPC with messaging semantics (async, a single argument data payload), and you can use a messaging system with RPC semantics (i.e. tunneling RPC over HTTP, using HTTP as transport). I think we basically have to stop using the word RPC as a catch-all for so many systems, and identify which choices are good and which ones lead to design mistakes.
    • m0th87 14y ago
      You can implement RPC in tuplespaces pretty easily: Client: out("rpc-request", uuid, "say_hello", "m0th") in("rpc-request", uuid, ?response) Server: in("rpc-request", ?uuid, ?method, ?arg) response = call(method, arg) out("rpc-request", uuid, response) The example is obviously a bit simplified, but it's certainly easy to do in generative communication. Message queues and tuplespaces are very different. A tuplespace allows pattern matching on tuples. And many tuplespace implementations do not provide monotonicity.
      • chubot 14y ago
        Well I should have clarified that I was basing that on my interpretation of the terms RPC and message queue. The important bit is that all these debates are obscured by imprecise terminology. RabbitMQ supports reciving messages based on a pattern: http://www.rabbitmq.com/tutorials/tutorial-five-python.html http://www.rabbitmq.com/tutorials/tutorial-five-python.html It also says it supports RPC: http://www.rabbitmq.com/tutorials/tutorial-six-python.html http://www.rabbitmq.com/tutorials/tutorial-six-python.html That doesn't match my definition of RPC, but OK. I consider RPC server-to-server, not server -> "smart" intermediary -> server. But I guess they want to to define RPC as request/reply. So again it's a terminology issue. What deployed, modern systems use tuple spaces and are substantively different from a message queue? My impression is that "tuple spaces" were the historical name, from Gelertner's papers, but everyone just calls them message queues. Message queues have lots of different properties but the defining one, as in tuple spaces, is that there's an intermediary between 2 servers. The sender and receiver don't have to be up at the same time.
        • m0th87 14y ago
          > What deployed, modern systems use tuple spaces and are substantively different from a message queue? None that I know of, but that's because no one uses generative communication nowadays :) > Message queues have lots of different properties but the defining one, as in tuple spaces, is that there's an intermediary between 2 servers. That's a very loose definition that could classify a lot of things as message queues. Generative communication says nothing about how the semantics are implemented; they may use an intermediary, or they may not. The early version of C-Linda did not use intermediaries, and was intended for in-process communication. Of course, a practical, distributed implementation of generative communication uses intermediaries. But then again, depending on the implementation, it may be distributed across multiple intermediaries. I would say a message queue would necessarily have monotonicity (the name surely implies it!), which generative communication does not have. > The sender and receiver don't have to be up at the same time. In academic parlance this is called time decoupling, and it is an awesome property. ZeroRPC has this as well thanks to 0mq. I don't really know anything about RabbitMQ to comment. I think I've heard that some engineers at dotCloud tried it out for our distributed communication needs, and it just couldn't scale to our load. But that would've been a while ago, and it has probably improved substantially since.
  • astrodust 14y ago
    Ruby has had DRB since as long as I can remember, a form of remote procedure call in the most literal sense, objects sending messages to other remote objects and getting answers back, but I've never seen it used in any serious capacity. Perhaps it was because of how XMLRPC and related nonsense poisoned the well. Times are different now. Developers are embracing asynchronous methods on platforms that used to be strictly synchronous and they're learning to adapt to the fact that your method calls take time to complete, or may not complete at all if you're not careful in your design. jQuery and related methods are RPC in a very primitive sense. Backbone is a step towards a more Meteor-like paradigm that should serve as a more solid foundation for "modern" RPC.
  • mcguire 14y ago
    Actually, one of the major difficulties with CORBA was with the CORBA standards themselves, which did not do a very good job defining asynchronous calls and rendered them pretty darn useless. Check out one of Vinoski's other publications, Advanced CORBA Programming with C++ for more details. (I'll admit I didn't even try to read the CORBA standards.) [Edit: Oh, and tuple-spaces are cool.]
• joshu 14y ago
  Nit: Google's RPC is not Protocol Buffers. That's just a serialization they use.