[zeromq-dev] async client design
ilejncs at narod.ru
Mon Aug 16 15:09:00 CEST 2010
Matt, you are right: it is probably more natural to use UPSTREAM/DOWNSTREAM pair. Although I don't see great difference
between UPSTREAM/DOWNSTREAM pair and one XREQ at client side.
Am I missing something?
Imagine, for example, we are writing a sort of Web crawler.
- some HTTP downloading (which is slow and we don't want to have a thread per TCP session)
- connect to a Server via 0mq for some processing
It is rather natural to have communications with the Server in the same eventloop.
I think I can illustrate my question by Option (2) client implementation. It is here http://pastebin.com/ve5Q6nVp
(no HTTP or something, just 0mq in eventloop). The server based on "multithreaded server in 10 mins" with minor
modifications http://pastebin.com/2Nwh0x8P .
My original questions were if a bunch of REQs socket is a problem from performance point of view and if every REQ socket
uses dedicated TCP session.
Unfortunately answers are Yes and Yes.
As a conclusion I probably go with Option (1) powered by UPSTREAM/DOWNSTREAM, unless better design is suggested.
13.08.10, 16:56, "Matt Weinstein" <matt_weinstein at yahoo.com>:
> 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:
> > 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 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 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
More information about the zeromq-dev