I've currently got a vast array of custom protocols that all rely on client-server (point 2 point) communications. This is getting very messy to configure (each client must have a host/port for each server it connects to - and these must be maintained when a server moves etc. even with virtual hosts this is a pain!).
I'm considering moving my architecture to a message broker infrastructure where a centralised broker sorts out which messages go where and provides vastly simplified configuration for clients. Now I can name environments by name and not worry about host/ports for each of the components that make up that environment. The problem is, whilst there is plenty of introductory tutorials for AMQP, there isn't many real-life examples that go into details about how servers detect whether a client has dropped off the comms bus or other such scenarios.
For example:
One server listens for subscription requests and starts flowing feeds down to a client when requested. Currently, if the client dies or drops off, we detect that by the socket dropping or a heartbeat timeout.
My question is using a message broker, should I maintain the heartbeat timeout system? How do servers know when to stop feeding these subscriptions?
Or should I start thinking another way, that servers should always feed the information and allow the message broker to drop unwanted messages? (This seems pretty wasteful to me... and not always possible).
I'm considering moving my architecture to a message broker infrastructure where a centralised broker sorts out which messages go where and provides vastly simplified configuration for clients. Now I can name environments by name and not worry about host/ports for each of the components that make up that environment. The problem is, whilst there is plenty of introductory tutorials for AMQP, there isn't many real-life examples that go into details about how servers detect whether a client has dropped off the comms bus or other such scenarios.
For example:
One server listens for subscription requests and starts flowing feeds down to a client when requested. Currently, if the client dies or drops off, we detect that by the socket dropping or a heartbeat timeout.
My question is using a message broker, should I maintain the heartbeat timeout system? How do servers know when to stop feeding these subscriptions?
Or should I start thinking another way, that servers should always feed the information and allow the message broker to drop unwanted messages? (This seems pretty wasteful to me... and not always possible).
