A few years ago, I created a simple Broker (middle layer) program with NetMQ (C# implementation of ZeroMQ)
I did not have to worry about a "Heartbeat" because the way the...
Client <--> Broker <--> Worker
...would communicate already handled it for me.
As for the Worker would send a message to the Broker like "Do you have anything for me?" and the Broker would either respond with "Nothing at the moment" or "Yes.. here you go!"
Either way, we have confirmation between the two services. The Broker keeps a log of the last interactions.. and so does the Worker. If the Worker has not heard back from the Broker in about 10 mins, would attempt to reconnect. If this fails 3 times, would send out an email.
Same for the Broker. If it has not heard anything from the Worker, will send out an email.
As for the Client, that will always send new messages to the Broker. It also keeps tabs on all messages, ensuring the Broker confirms the message is Completed before removing it from the Client system. Every now and then the Client asks "if this was processed" to which the Brokers responds with "No.. still processing" or "Successful/Error"
Regardless, it has a "heartbeat" by default, as well as reliability and low chance of data loss (well, data can get lost... trying to work out a perfect system is difficult but we had something decent beyond the scope of this post)
It was a good system. It was light and requests from the client or worker was responded fast by the broker. Was pretty fast compared to the old system which was relying on SQL Server queries to check states of data, with SQL Server replication on the client systems. It was a "quick and easy" solution when you had 10 clients. Once it got to over 40 it concerned me a lot.
I did not have to worry about a "Heartbeat" because the way the...
Client <--> Broker <--> Worker
...would communicate already handled it for me.
As for the Worker would send a message to the Broker like "Do you have anything for me?" and the Broker would either respond with "Nothing at the moment" or "Yes.. here you go!"
Either way, we have confirmation between the two services. The Broker keeps a log of the last interactions.. and so does the Worker. If the Worker has not heard back from the Broker in about 10 mins, would attempt to reconnect. If this fails 3 times, would send out an email.
Same for the Broker. If it has not heard anything from the Worker, will send out an email.
As for the Client, that will always send new messages to the Broker. It also keeps tabs on all messages, ensuring the Broker confirms the message is Completed before removing it from the Client system. Every now and then the Client asks "if this was processed" to which the Brokers responds with "No.. still processing" or "Successful/Error"
Regardless, it has a "heartbeat" by default, as well as reliability and low chance of data loss (well, data can get lost... trying to work out a perfect system is difficult but we had something decent beyond the scope of this post)
It was a good system. It was light and requests from the client or worker was responded fast by the broker. Was pretty fast compared to the old system which was relying on SQL Server queries to check states of data, with SQL Server replication on the client systems. It was a "quick and easy" solution when you had 10 clients. Once it got to over 40 it concerned me a lot.