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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
