[zeromq-dev] async client design
matt_weinstein at yahoo.com
Fri Aug 13 14:56:21 CEST 2010
If the clients are asynchronous you may be using the wrong socket
type, you might look at using PUSH/PULL or PAIR (depending on your
thread configuration), tag each endpoint with per request UUIDs and
junction them into an XREQ with REP servers. You can keep a count of
requests outstanding by stream and limit it.
PAIR requires that the same thread push and pull, whereas PUSH/PULL
you would set up one upstream and one downstream, and your end user
could have a recv thread and a separate send thread if needed (current
For more suggestions, please send more details about the application ...
On Aug 13, 2010, at 7:33 AM, Ilja Golshtein wrote:
> I am thinking about single thread client design.
> The server is parallel, some requests are slow, so it must be
> possible to send N+1 request before Nth is processed.
> The problem is client have to associate response with request for
> further processing.
> Actually, the option (0) is to send some extra data together with
> request and simply get it back from server, though it is not perfect
> of traffic considerations.
> Option (1):
> One XREQ socket.
> Some storage for extra info (e.g. std::map<REQUEST_ID, EXTRA_INFO>),
> request_id sent as part of a message and returned from server.
> Option 2:
> Pool of REQ sockets.
> Some storage for extra info (e.g. std::map<ZERO_MQ_SOCKET,
> When zmq_poll is done, client looks for extra_info based on socket
> Please, comment option (2). Is it Ok to have several dozens REQ
> sockets? Is it true this approach
> leads to the same number of TCP connections between client and server?
> Suggestions are appreciated.
> Best regards,
> Ilja Golshtein.
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev