-
Notifications
You must be signed in to change notification settings - Fork 434
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[enhancement] Multiple MQTT brokers #207
Comments
(honest question) Is that better than federating from the local MQTT broker to the cloud broker? |
Yes if you would like to "survive" with cloud broker updates/feeds in case of local broker failure and you do not care that same traffic gets transferred twice on local network. |
fair enough. |
@muhlpachr is that what https://aws.amazon.com/greengrass/ is trying to do? |
I am not sure that this fallback functionality should be on the Mongoose OS side. If there is a local MQTT broker already, it makes sense for Mongoose OS to be configured to use it. Local broker should either forward traffic to the remote one, or spool if there is no connection. |
How local MQTT broker can do anything in case it dies (e.g. hw failure) ? |
Fair question. However, implementing fallback is a non-trivial task. How a failure is detected, at which point the switch happens, how to go back to the main target, should the device spool data locally if both targets fail and during the switch, etc etc.. Then, a fair question will arise - if done for MQTT, why not for HTTP? WebSocket? How authentication is handled? Security-wise, this is a huge potential for attacks. So, the answer is: no fallbacks at this point in time. Too messy. Use things like AWS GreenGrass if fallback is needed. |
Why one would like to detect failure at client side if amount of traffic is not problem ? Why client can not afford to establish more simultaneous connections to MQTT brokers ? Why not HTTP or WebSocket ? Because there is not Pub/Sub abstraction. MQTT PUBLISH is not dependent on MQTT broker (address of MQTT broker is not used) and same for SUBSCRIBE. MQTT has shadow service client and whole shadow abstraction does not have any issues with multiple parallel MQTT broker connections. Authentication data is just per MQTT broker configuration as it is now. |
AWS GreenGrass is for moving Lambda functions to on-premise compute resources (or to manage on-premise computer resources same way as Lambda functions). Do you expect to implement availability cluster MQTT broker in Lambda functions ? |
Hi, I have a simple use case for being able to configure multiple MQTT servers. Another MQTT is local for Home Assistant, ie mosquitto running on a customer's raspi. Want to be able to selectively publish a message to a specific MQTT resource. Optional argument. If no argument it uses the default primary. |
@markterrill interesting. please file as a new issue under https://github.com/mongoose-os-libs/mqtt |
|
Use case: simultaneous cloud MQTT broker and local MQTT broker.
Local MQTT broker can serve local clients even in case of Internet connectivity outage.
The text was updated successfully, but these errors were encountered: