[zeromq-dev] local IPC

Brian Knox briank at talksum.com
Wed Nov 28 14:51:27 CET 2012


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 <M.Hua at gmx.de> 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 <briank at talksum.com>
> > An: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> > 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 <M.Hua at gmx.de> 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
> > > 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/20121128/4e213e93/attachment.htm>


More information about the zeromq-dev mailing list