I am using ZMQ NetMQ package in c# to receive the message from the subscriber. I am able to receive the msg but I am sticking in the while loop. I want to break the while loop if the publisher is stopped sending data.
Here is my subscriber code:
using (var subscriber = new SubscriberSocket())
{
subscriber.Connect("tcp://127.0.0.1:4000");
subscriber.Subscribe("A");
while (true)
{
var msg = subscriber.ReceiveFrameString();
Console.WriteLine(msg);
}
Q : "How to check ZMQ publisher is alive or not in c# ?"
A :
There are at least two ways to do so :
a )
modify the code on both the PUB-side and SUB-side, so that the Publisher sends both the PUB/SUB-channel messages, and independently of that also PUSH/PULL-keep-alive messages to prove to the SUB-side it is still alive, as being autonomously received as confirmations from the PULL-AccessPoint on the SUB-side loop. Not receiving such soft-keep-alive message for some time may trigger the SUB-side loop to become sure to break. The same principle may get served by a reversed PUSH/PULL-channel, where SUB-side, from time to time, asks the PUB-side, listening on the PULL-side, using asynchronously sent soft-request message to inject a soft-keep-alive message into the PUB-channel ( remember the TOPIC-filter is a plain ASCII-filtering from the left to the right of the message-payload, so PUSH-delivered message could as easily send the exact text to be looped-back via PUB/SUB back to the sender, matching the locally known TOPIC-filter maintained by the very same SUB-side entity )
b )
in cases, where you cannot modify the PUB-side code, we still can setup a time-based counter, after expiring which, without receiving a single message ( be it using a loop of a known multiple of precisely timed-aSUB.poll( ... )-s, which allows for a few, priority-ordered interleaved control-loops to be operated without uncontrolled mutual blocking, or by using a straight, non-blocking form of aSUB.recv( zmq.NOBLOCK ) aligned within the loop with some busy-loop avoiding, CPU-relieving sleep()-s ). In case such timeout happens, having received no actual message so far, we can autonomously break the SUB-side loop, as requested above.
Q.E.D.