Hi again, Attila, Attila Magyari <[email protected]> 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.
signature.asc
Description: PGP signature
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
