[zeromq-dev] async client design
Alexey Ermakov
zee at technocore.ru
Mon Aug 16 15:32:02 CEST 2010
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100816/6bf0c1a8/attachment.htm>
More information about the zeromq-dev
mailing list