[zeromq-dev] equivalent of accept

Martin Sustrik sustrik at 250bpm.com
Mon Apr 26 20:05:48 CEST 2010


Brian,

> Are the semantics of XREQ/XREP sockets documented anywhere? I don't see them
> mentioned at http://api.zeromq.org/zmq_socket.html

It's work in progress so it's deliberately undocumented.

> If I've understood your narrative above, the solution looks like this(*):
> 
>     +--------------+
>     |        * ------.
>     |       REQ    |  |  +----------------------------+
>     +--------------+  |  |    zmq_device     workers  |
>         Client 1      |  |      *    *   ,--- * REP   |
>     +--------------+   `----.  /      \ ,---- * REP   |
>     |        * -------------- *        * ---- * REP   |
>     |       REQ    |     |   XREP    XREQ             |
>     +--------------+     +----------------------------+
>         Client 2                    Server
>          ... etc

Yes.

> Clearly, a request from client 1 which goes to one of the workers must have
> its response routed back to client 1 (and ditto client 2).  Indeed, if
> client 1 has multiple TCP connections to the server, the response must be
> routed down the *same* TCP connection as the request came in.
> 
> So I guess that the XREP and XREQ endpoints must somehow tag each request
> to allow the response to be routed back correctly.
> 
> If so, are these tags only part of the socket API? Or can you run XREP-XREQ
> over TCP, so the tags appear on-the-wire?

Yes, tags do appear on the wire.

>> However:
>>
>> 1. The XREP/XREQ sockets are broken in a current trunk. I need one full 
>> day with no distractions to focus on it :(
> 
> Ah, then I can't try it out yet anyway :-)

Well, you can use 2.0.6 which kind of works - with the caveat of REP 
socket not stripping the tags from the message, so you'll have to do 
that by hand.

> (*) Aside: if the REP socket were built into the stack proper I'd expect it
> to be thread-safe, so workers could just pop messages directly, without the
> zmq_device in the middle. That would simplify the above diagram a lot.

That would decrease the performance by an order of magnitude. Moreover 
it has unclear semantics.

> Another aside: it's interesting to note that the workers with a REP socket
> open a connection to a REQ socket; that's "backwards" with respect to the
> message flow, but a nice way for workers to be added and removed
> dynamically.  I've seen something similar done for HTTP, called "swiftiply",
> but the project page seems to have gone.

The idea is that transient "applications" such as workers or clients 
connect to well-known endpoints (such as the device in the middle of 
your diagram).

Martin



More information about the zeromq-dev mailing list