[zeromq-dev] Full-Dublex communication, some questions.

[Goswin von Brederlow]

On Wed, Jul 09, 2014 at 12:40:55PM +0200, Kurt Degiorgio wrote:
> Hi,
> 
>  
> 
> I am looking to implement a system, where the server controls a number of
> agents and send them processing tasks, the agents will then update the server
> (asychnrously) of the progess of the task and finally send the result of the
> task to the server.
> 
>  
> 
> Each server can have multiple agents, and each agents can have multiple
> servers.
> 
>  
> 
> I was looking at a dealer/router, the server won?t just randomly push tasks on
> to the clients  (hence why pub/sub won?t work)it needs to route them to agents
> according to how busy the agents are and the task at hand (some tasks require
> specific agents to be completed)
> 
>  
> 
> Some questions:
> 
>  
> 
> 1.       Is this the right approach? (using dealer/route)

That depends on more factors that you gave. From what you said so far
it would work though.
 
> 2.       Will the agent be able communicate with the server asynchronously?
> (full dublex)

That depends on you. You need to use async I/O. See 3.
 
> 3.       Regarding recv, is there some possible event-based system in place?
> (i.e I give zeroMQ a callback and every time data is received zeroMQ calls that
> callback) because from my perspective constantly polling zeroMQ for data is not
> very efficient and will require  a dedicated thread.

There are several such systems, depends on what language you use as well.
But they are addons to libzmq and not itself part of libzmq.

For exampl the high-level C bindings for zmq (http://czmq.zeromq.org/)
have a zloop module.


The low-level solution to this problem though is to zmq_poll() the
socket(s). This will block untill there is activity on one of the
sockets or a timeout is reached. It doesn't just loop over all sockets
continiously checking them for activity in a busy loop. So efficiency
is not an issue.

> Thanks!
> Kurt.

MSG Goswin

> DISCLAIMER
> The information contained in this electronic mail may be confidential or
> legally privileged. It is for the intended recipient(s) only. Should you
> receive this message in error, please notify the sender by replying to this
> mail. Please do not read, copy, forward or store this message unless you are an
> intended recipient of it - unauthorized use of contents is strictly prohibited.
> Unless expressly stated, opinions in this message are those of the individual
> sender and not of GFI. While all care has been taken, GFI is not responsible
> for the integrity of and that of the contents of this electronic mail and any
> attachments included within.

DISCLAIMER
This is a public mailinglist. The intended recipient(s) are the world,
the galaxy, the universe, the multiverse. Any information posted is
out there for anyone to see and any expectation of privacy is
non-existant. All use of contents is allowed and eventually will
happen somewhere, sometime. While all care has been taken, this sender
is not repsonsible for readers without a sense of humor.