[zeromq-dev] async client design

[Ilja Golshtein]

Hello!

  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?

  About details.
  Imagine, for example, we are writing a sort of Web crawler.
  It does
- 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.

Many thanks.



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  
>  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 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
>  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>  
>  

-- 
Best regards,
Ilja Golshtein.