[zeromq-dev] 0MQ + standard RPC
Matthew Long
matthew.long at aptomar.com
Mon Nov 28 14:00:56 CET 2011
Right,
Conceptually a complete RPC system has:
i) An underlying connection or transport between two endpoints.
ii) A mechanism to handle reading and writing data from the connection
iii) A codec to transform data from a language-specific meaning to a common wire format
iv) An RPC system to do something with the messages
The points you mentioned are definitely part of this. 0MQ provides a very nice transport. But since I am lazy, I'd like to not have to handle ii-iv myself.
Those are the big pieces. There are other considerations as well:
* Language-specific methods for handling the RPC call. An idiomatic RPC layer for Java will be different than C++, for example.
* Asynchronous calls. Often we'll want to have clients that can have several requests "in-flight" with asynchronous callbacks when particular calls complete. I've been looking at XREQ/XREP for this (similar to the example in the guide). In this case, REQ/REP is not really sufficient.
One thing I like about 0MQ is that with multipart messages we could use the transport layer to do more interesting routing than is normally the case with pure TCP. This could actually be quite interesting in our domain.
Matt
On Nov 28, 2011, at 12:29 PM, Martin Sustrik wrote:
> Hi Matthew,
>
>> We will heavily leverage the 0MQ PUB/SUB functionality in most of the
>> communication layer that we are building. The RPC portion is just
>> one piece of what we are doing -- in general it is simply going to be
>> the control channel.
>>
>> If 0MQ is not a good fit for this piece, it is not a big deal, but I
>> had hoped that some of what you have built into 0MQ (such as durable
>> sockets) could help simplify some of the application layer.
>
> Ok. I see.
>
> Basically, RPC is the REQ/REP pattern.
>
> What you are missing for full-blown RPC solution is:
>
> 1. Serialisation -- this is delberately decoupled from 0MQ. As a
> consequence you can use any serialisation library you like.
>
> 2. Resending of the request is case the server dies. This should be and
> will be done inside of 0MQ, but is not done yet. However, it can be
> easily emulated on top of it.
>
> Anything I've missed?
> Martin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
More information about the zeromq-dev
mailing list