If I understand you correctly - you have 3 clients connected to a server using a DEALER / ROUTER connection. The server sends a single message. One client received the message and the other two do not.
If what I described is what you are doing, this is exactly what should happen. It might be a good idea to read (or reread) the zeromq guide ( http://zguide.zeromq.org/ ) and the documentation on zmq_socket, and how the different socket types interact: http://api.zeromq.org/3-2:zmq-socket Brian On Wed, Nov 28, 2012 at 7:35 AM, Martin Hua <[email protected]> wrote: > Hello, > > thanks for your answer Mr Knox. > > Now I have the following problem: > Yesterday I have implemented a server- and a client-application that talk > with each other synchronously. My goal is that all clients receive the > reply from the server simultaneously. > I have used the example from the chapter "Shared Queue (DEALER and ROUTER > sockets), Figure 17 - Request-reply Broker" to implement my goal. > > But after I have started i.e. one server-application and three > client-application, the three client-application don't receive the reply > from server at the same time. > Only one of this clients receive the reply. > > So my question is whether there is a possibility to send a reply to the > clients at the same time. I have thought that this example solve my problem. > > Best regards, > Martin > > > > -------- Original-Nachricht -------- > > Datum: Tue, 27 Nov 2012 06:49:17 -0500 > > Von: Brian Knox <[email protected]> > > An: ZeroMQ development list <[email protected]> > > Betreff: Re: [zeromq-dev] local IPC > > > This may be helpful: > > > > http://api.zeromq.org/3-1:zmq-socket > > > > "*Key differences to conventional sockets* > > > > Generally speaking, conventional sockets present a *synchronous* > interface > > to either connection-oriented reliable byte streams (SOCK_STREAM), or > > connection-less unreliable datagrams (SOCK_DGRAM). In comparison, ØMQ > > sockets present an abstraction of an asynchronous *message queue*, with > > the > > exact queueing semantics depending on the socket type in use. Where > > conventional sockets transfer streams of bytes or discrete datagrams, ØMQ > > sockets transfer discrete *messages*. > > > > ØMQ sockets being *asynchronous* means that the timings of the physical > > connection setup and tear down, reconnect and effective delivery are > > transparent to the user and organized by ØMQ itself. Further, messages > > may > > be *queued* in the event that a peer is unavailable to receive them." > > > > > > > > > > On Tue, Nov 27, 2012 at 3:40 AM, Martin Hua <[email protected]> wrote: > > > > > Hello everybody, > > > > > > for my Bachelor thesis I need a synchronous communication for my > > programm. > > > > > > To see how the local IPC communication under zeroMQ operates, I have > > used > > > the function zmq_send() and zmq_recv() after the generation of the > > socket > > > with ZMQ_REQ and ZMQ_REP. > > > > > > After the implementation, I have seen that the communication operates > > > asynchronous. > > > > > > So my question is, whether zeroMQ supports synchronous communication. > > > I thought that the request-reply Pattern is synchronous. > > > > > > I thank you for your answers in advance. > > > > > > Best regards, > > > Martin > > > > > > _______________________________________________ > > > zeromq-dev mailing list > > > [email protected] > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
