Is there a way to protect the broker from too many packages originating from one client?

[Max G]

I had the following situation:

On a property automation system with many controllers talking to each other and an automation system controlling them all, one of the controllers crashed and went into an endless publish loop and caused the automation system to become very sluggish due to processing the updates.

The broker was holding up, but the automation system was hours behind processing 'real data' after the controller sent 100s of thousands of messages over night (some 8 hours).

While the root cause of the buffer overflow causing the crash has been fixed; a mqtt client could always misbehave for any number of reasons, thus flooding the broker.

I am looking for ways, such as listening to the number of posts from a client, and isolate the client. Not sure ho I do the latter, but managed switches may allow for Ethernet port isolation.

Anyone knowing any solutions for this problem?

[Andy Stanford-Clark]

There’s no silver bullet, but one solution I’ve used in the past is to just lock out the credentials of the errant device, so it can’t connect.

Hopefully there’s a “polite” reconnect period on the device, so the failure to connect doesn’t cause a similar impact on the broker (at least you won’t be getting the flood of data on your back-end applications, though).

If you need to “bounce” a device off a broker (e.g. when you’ve revoked its credentials and need it to try to reconnect so you can deny it access), connecting a client with the same clientID will cause the previous connection (i.e the device you’re trying to bounce) to be dropped by the broker. 

If the device connects again, the broker would bounce your other client, and so on; but you only need to do it once, then the device won’t succeed in getting in after that (as you’ve revoked the credentials).

Some commercial broker products (e.g. from IBM), ISTR, include what we called “crying baby” support, which looks for clients that are excessively “needy” and locks them out.

#MQTTfoo ;)

Andy

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at https://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.