New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Race condition with received message causes ZMQ_CONNECT_ROUTING_ID to be assigned to wrong socket #3191
Comments
As the zmq_setsockopt manpage says, you must set the options before connecting/binding apart from a restricted set of options. |
In the test I provided the option is set before connecting:
While in the zmq_connect call, a received message from a different socket (yconn) is processed, leading to the misasssignment of the "Z" id to the Y socket. |
mvilim
pushed a commit
to mvilim/libzmq
that referenced
this issue
Jul 25, 2018
…nnection (Issue zeromq#3191) Solution: Add an identifier parameter for local attach to zmq::socket_base_t::attach_pipe
mvilim
pushed a commit
to mvilim/libzmq
that referenced
this issue
Jul 26, 2018
…nnection (Issue zeromq#3191) Solution: Add an identifier parameter for local attach to zmq::socket_base_t::attach_pipe
Fixed by #3193 |
MohammadAlTurany
pushed a commit
to FairRootGroup/libzmq
that referenced
this issue
Jan 28, 2019
…nnection (Issue zeromq#3191) Solution: Add an identifier parameter for local attach to zmq::socket_base_t::attach_pipe
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue description
There is an problem when a ROUTER socket is trying to connect to another socket using ZMQ_CONNECT_ROUTING_ID while receiving messages from a third socket. If a message is received (in the io thread) between setting the socket option and connecting to the socket, the routing id can be applied to the socket from which we received the message instead of the socket to which we are connecting.
I believe this is caused by socket_base_t::connect where pending commands are processed. If we process a command where a received message causes us to bind to new socket, we will use the routing id for that socket rather than the target of the connect call. The same behavior can be triggered by setting ZMQ_CONNECT_ROUTING_ID and then sending or receiving messages on the same socket (as that will also trigger process_commands).
I believe a possible solution is to change identify_peer in the stream and router socket implementations so that they can differentiate between peers being connected to from a local connect call (possibly by passing another argument in) and peers being connected to because of a received message.
I'm open to trying to write a pull request for this, but I first wanted to validate that those more familiar with the library see it as a bug. According to the docs, the option should only apply to sockets connected to via zmq_connect: "The ZMQ_CONNECT_RID option sets the peer id of the next host connected via the zmq_connect() call, and immediately readies that connection for data transfer with the named id". With the current behavior, there is no way to use ZMQ_CONNECT_ROUTING_ID reliably on a socket that is also receiving connections.
Environment
Minimal test code / Steps to reproduce the issue
What's the actual result? (include assertion message & call stack if applicable)
The Y socket receives the message sent from X to identity Z. The assertion on line 82 of the test above will fail.
What's the expected result?
The Z socket should receive the message. You can change the likely winner of the race by removing the first call to msleep. This will cause the X socket to (likely) connect to Z and apply the routing id before it receives the message from Y.
The text was updated successfully, but these errors were encountered: