[zeromq-dev] Clever uses of XREP/XREQ

[Martin Sustrik]

Brian,

> We are using XREQ/XREP a lot these days and one of our developers came
> across some interesting uses of them.  I wanted to see if these uses
> were official supported, see if others were doing these types of
> things and point out these interesting cases to others.

...


> We think these are pretty clever uses of these socket types.  Some questions:
> 
> * Is this supported behavior (please say yes) or might this go away in
> the future?
> * Are there any issues to be aware of that we might run into in this
> configuration in a high load context?
> * Anyone else using these or other sockets in creative ways?

To get a clear idea of what's going on you have to take a bit different 
point of view: Think of XREQ/XREP as IP and REQ/REP as TCP. Basically, 
two different layers of the stack.

Now image a person used to TCP. At some point he discovers IP and 
becomes enthusiastic about it: Wow! You can send packets to any address, 
not just to the peer! Wow! You can get a packet from any peer without 
need to listen/accept new connections! etc.

The above is true but there's a couple of caveats:

1. If you need any of TCP features (realiability, congestion control) 
you have to implement it yourself.
2. If you want to interoperate with an application using TCP, you won't 
be able to (unless you reimplement TCP in your app).

Same applies to XREQ/XREP. It's a low-level protocol. You've built 
couple of protocols on top of it (one-request-many-replies, 
identify-on-connect). In theory these can be made to alternative 
upper-layer protocols (messaging patterns, socket types) at the same 
level as REQ/REP.

If you want to go that way, the questions to answer are: Are the 
semantics of the pattern coherent? Does it work as expected in all 
contexts (different transports, topologies etc.) Does it scale? Etc.

Martin