Skip to content
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

Closed
muhlpachr opened this issue Mar 10, 2017 · 12 comments
Closed

[enhancement] Multiple MQTT brokers #207

muhlpachr opened this issue Mar 10, 2017 · 12 comments

Comments

@muhlpachr
Copy link

Use case: simultaneous cloud MQTT broker and local MQTT broker.
Local MQTT broker can serve local clients even in case of Internet connectivity outage.

@MobiusHorizons
Copy link

(honest question) Is that better than federating from the local MQTT broker to the cloud broker?

@muhlpachr
Copy link
Author

muhlpachr commented Mar 10, 2017

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.

@MobiusHorizons
Copy link

fair enough.

@cpq
Copy link
Member

cpq commented Apr 3, 2017

@muhlpachr is that what https://aws.amazon.com/greengrass/ is trying to do?

@cpq
Copy link
Member

cpq commented Apr 9, 2017

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.

@cpq cpq closed this as completed Apr 9, 2017
@muhlpachr
Copy link
Author

How local MQTT broker can do anything in case it dies (e.g. hw failure) ?

@cpq
Copy link
Member

cpq commented Apr 10, 2017

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.

@muhlpachr
Copy link
Author

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.

@muhlpachr
Copy link
Author

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 ?

@markterrill
Copy link
Contributor

Hi, I have a simple use case for being able to configure multiple MQTT servers.
Primary MQTT is GCP for command/control/status

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.

@rojer
Copy link
Collaborator

rojer commented Jan 13, 2020

@markterrill interesting. please file as a new issue under https://github.com/mongoose-os-libs/mqtt

@markterrill
Copy link
Contributor

@markterrill interesting. please file as a new issue under https://github.com/mongoose-os-libs/mqtt
Cheers @rojer, have done so:
mongoose-os-libs/mqtt#14

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants