ZeroMQ c++ Send/Receive

AirTrav 0
Viewed 26

Here is once again an issue I don't get with ZeroMQ. My goal is to be able to send a simple message through a publisher and then to subscribe to a topic and to receive it. However, after some researches, I ended up writing this code that creates the sockets connection + sets the topic subscription, creates the message to send, sends it and receives it on the subscribers part.

However, when I run my code, it seems to block at the line sub.recv(rx_msg,zmq::recv_flags::none) where the message is being collected by the subscriber into a rx_msg. I then checked using wireshark to see what was going on between my two sockets and everything goes right (socket sub, scket pub, subscribe to topic) until the message is sent where I doint see anything happening. I can easily conclude that no message is being sent using the pub.send(message, zmq::send_flags::none) line. I then can't understand why this line doesn't do what I expect it to do. Is the socket.send() function not the one to be used here or is it the arguments I use in it that need to be changed.

zeromq c++
1 Answers

It's may be that you're running your publisher first, and then running your subscriber, and that your publisher is publishing a single message. Is that right?

If so, as I understand it, a PUB socket drops messages if the socket is in the mute state (not connected). So, if you run the publisher, and there's no subscriber already running and ready to connect, the publisher can "send" a message that just gets dropped. So, when your subscriber starts up it can connect and subscribe all it likes; if the publisher has already sent (and dropped) the only message it's programmed to send, the subscriber will then block waiting for a message.

There's probably no guarantee that it will work, even if the subscriber is run first. Establishing a connection takes time, and there's likely a race between that happening and the publisher sending a message whilst the socket is not yet connected.

Generally speaking, PUB / SUB is intended for a sitation when the publisher is going to keep sending messages regardless (or at least, that's what I thinkg), and any subscribers that happen to be connected will get messages when they're sent. You can think of it like subscribing to a newspaper - you won't get all previous editions ever printed sent to you, instead you'll get the next new edition following your subscription request being processed.

If my assumption about the runtime sequence is wrong, then I'm not sure what's going wrong. Code would help!

bazza0
Related