Skip to content
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

Bind sockets with same inproc address on different io_contexts fails #163

Open
KnoerleMan opened this issue Jul 21, 2020 · 0 comments
Open

Comments

@KnoerleMan
Copy link

Situation:
I have a class with an boost::asio::io_context and multiple azmq::sockets as members.
One of the sockets is used as a ROUTER socket and connect to a "external" socket via ipc transport.
This socket also calls bind on a hard coded inproc address, specified as followed: "inproc://client_router".
Two other sockets (DEALER) of this class will now be connected to the router socket.
The connect and bind actions are done when calling the method "open".

Problem:
If i use this class and instantiate two objects i can call "open" on the first object without any problems.
But when i call "open" on the second object i receive the error message "Address already in use" after bind is called on the router socket.
I also checked the storage address of the io_contexts and they are different on both objects. So there seems to be no "magic merging" of the two contexts behind the scenes. But it feels like.

Other Test:
When the class is used in two separate processes with one object on each process there is no error when calling open on both.

Question:
When reading the zeromq documentation there should be no problem with reused inproc addresses, as far as they are used in different contexts.
This seems to be only valid for zeromq contexts created via zmq_init, but not for boost::asio::io_context?
Any other suggestions on this problem?

"Solution":
When changing the address to a unique one the problem disappears. I still would like to know why this fails with the same address used on different contexts. As stated in the zeromq doc's this should be a valid handling.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant