Congestion: Always Ignore MQTT by default #8634
Conversation
|
MQTT backhauls are somewhat critical in rural environments and having everyone have to have this disabled I don't believe is a good idea. Because even if the message is hopped over MQTT then broadcasted by an RF tower, the client would still ignore it. I think you would end up with a fractured environment where clients are missing messages because of infrastructure challenges. The other option would be for MQTT infrastructure backhaul nodes to suppress the MQTT tagging so it could be broadcast as expected. |
Even in small meshes it remains the case that a single MQTT-Downlink node can crush a real RF mesh.
This would take the current problem and make it even worse. |
If done properly this would be the best way. It feels like we are throwing the baby out with the bathwater with this change. |
It's simply not possible to do this properly 😅 If a node can be setup to un-taint an MQTT message, anyone could configure a node to do that and crush an RF network with no means for recourse (Ignore MQTT becomes meaningless and then you can't opt-out). |
|
I just don't see a kind way to inform the local mesh users on how to best do this. This goes against a lot of ease of entry mindsets and increases users friction with the product. I’m not saying I don’t like the concept, but this implementation needs to a way to make it easy for users, otherwise we’re making it more challenging. |
|
After a lengthy discussion an additional flag of "Zero Hop MQTT" is where conversation moved towards. Let's not merge this until we have a better understanding of overall direction to not increase day to day user friction |
3 participants
It's no secret that one poorly configured MQTT Downlink can send a mesh into a tailspin.
We currently Ignore MQTT in regions with any duty cycle imposed, I propose we simply extend this to be globally ignored as a more sensible default. Effectively this prevents MQTT messages from propagating through an RF network without explicitly opting in.