[zeromq-dev] Which socket to choose?

Brett Viren bv at bnl.gov
Tue Aug 20 14:36:36 CEST 2019


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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20190820/3c681645/attachment.sig>


More information about the zeromq-dev mailing list