[zeromq-dev] async client design

[Matt Weinstein]

Sorry, I was tied up yesterday.

It's just a matter of whether or not you will be single-threaded  
facing ØMQ.  If you are, all is well.  But then you have to construct  
the appropriate UUIDs yourself.  You might be better off using XREP  
and REQ, at least then the server threads generate the UUIDs for you :-)

Otherwise, send a diagram :-)

On Aug 16, 2010, at 9:32 AM, Alexey Ermakov wrote:

> Hi Matt,
>
> What are the downsides of using just one XREQ socket on the client  
> side (other than the thread-safety restriction)? PUSH/PULL require  
> two different endpoints, which doesn't seem right (at least as a  
> public API, the client will probably have to separate into PUSH/PULL  
> streams to handle sending/receiving properly).
>
> On Fri, Aug 13, 2010 at 4:56 PM, Matt Weinstein <matt_weinstein at yahoo.com 
> > wrote:
> 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
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100817/197cf974/attachment.htm>