[zeromq-dev] Which socket to choose?

Attila Magyari atti86 at gmail.com
Sat Aug 24 09:04:06 CEST 2019


Thanks Santosh,

I can make this work, but honestly it's over-complicated for a simple
client-server pattern. I feel like ZeroMQ is really lacking in this aspect.
I wish there would be some support for the draft sockets; even to make them
work as they are.

Regards,
Attila

On Tue, Aug 20, 2019 at 7:23 PM <Santosh.Bidaralli at dell.com> wrote:

> Hi Attila,
>
> Router-dealer combination is great for your design. You can refer to
> major-domo example in the guide which describes a great design for multi
> client-server application.
>
> Thanks,
> Santosh Bidaralli
>
> -----Original Message-----
> From: zeromq-dev <zeromq-dev-bounces at lists.zeromq.org> On Behalf Of Brett
> Viren via zeromq-dev
> Sent: Tuesday, August 20, 2019 7:37 AM
> To: Attila Magyari
> Cc: Brett Viren; ZeroMQ development list
> Subject: Re: [zeromq-dev] Which socket to choose?
>
>
> [EXTERNAL EMAIL]
>
> Hi again, Attila,
>
> Attila Magyari <atti86 at gmail.com> writes:
>
> > So having two sockets, one for sending and one for receiving is the
> > way to go?
>
> Disclaimer: I'm a zeromq amateur so take my advice as such.  I don't know
> if this two-socket approach is best but it's certainly one way to do it.
> (For a design that takes multi-socket communication to an extreme, check
> out the description in ipython's documentation about how it communicates
> between its parts.)
>
> > By message order restrictions I meant the send/recv pattern to be
> > unrestricted, no mandatory order of send/recv. The server could send
> > an arbitrary number of messages to the client.
>
> Okay.  I guess this ordering is referring to the "Send/receive pattern"
> eg as listed in the zmq_socket(3) man page.  REQ/REP is a lock-step
> pattern: send/recv/send/recv/send/recv...
>
> ROUTER and DEALER both have "unrestricted" send/receive pattern.  A ROUTER
> on the "server" side and a DEALER on each "client" may work for you.
> There's a bit of detail in that the ROUTER application has to manage a
> "routing id" as the first part of every message.  But, given that you can
> have two-way, 1-to-N, async message passing without a send/receive pattern
> restriction.
>
> > One-to-many as in one server socket to handle multiple client
> > connections, just like the CLIENT/SERVER sockets.
>
> ROUTER-DEALER fits this too.  Understanding your needs better now I would
> suggest checking if this pattern suits you before trying the two-socket
> approach.
>
> Cheers,
> -Brett.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20190824/a5b86cd1/attachment.htm>


More information about the zeromq-dev mailing list