[zeromq-dev] async client design

[Matt Weinstein]

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  
restriction).

For more suggestions, please send more details about the application ...

On Aug 13, 2010, at 7:33 AM, Ilja Golshtein wrote:

> Hello!
>
> 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  
> because
> 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,  
> EXTRA_INFO>).
> When zmq_poll is done, client looks for extra_info based on socket  
> fired.
>
> 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.
>
> Thanks.
>
> -- 
> Best regards,
> Ilja Golshtein.
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev