[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