ZeroMQ REQ/REP on ipc:// and concurrency
- by Metiu
I implemented a JSON-RPC server using a REQ/REP 0MQ ipc:// socket and I'm experiencing strange behavior which I suspect is due to the fact that the ipc:// underlying unix socket is not a real socket, but rather a single pipe.
From the documentation, one has to enforce strict zmq_send()/zmq_recv() alternation, otherwise the out-of-order zmq_send() will return an error.
However, I expected the enforcement to be per-client, not per-socket. Of course with a Unix socket there is just one pipeline from multiple clients to the server, so the server won't know who it is talking with. Two clients could zmq_send() simultaneously and the server would see this as an alternation violation.
The sequence could be:
ClientA: zmq_send()
ClientB: zmq_send() : will it block until the
other send/receive completes? will it return -1? (I suspect it will
with ipc:// due to inherent low-level problems, but with TCP it could
distinguish the two clients)
ClientA: zmq_recv()
ClientB: zmq_recv()
so what about tcp:// sockets? Will it work concurrently? Should I use some other locking mechanism to work around this?
