-
Notifications
You must be signed in to change notification settings - Fork 928
Design principles
Andy Piper edited this page Dec 4, 2013
·
2 revisions
MQTT was designed for low-bandwidth, high latency networks in the late 1990s/early 2000s. As a result, the designers made a number of key choices which influenced the way it "looks and feels".
- Simplicity, simplicity, simplicity! Don't add too many "bells and whistles" but provide a solid building block which can easily be integrated into other solutions. Be simple to implement.
- Publish/subscribe messaging. Useful for most sensor applications, and enables devices to come online and publish "stuff" that hasn't been previously known about or predefined.
- Zero administration (or as close as possible). Behave sensibly in response to unexpected actions and enable applications to "just work" e.g. dynamically create topics when needed.
- Minimise the on-the-wire footprint. Add an absolute minimum of data overhead to any message. Be lightweight and bandwidth efficient.
- Expect and cater for frequent network disruption (for low bandwidth, high latency, unreliable, high cost-to-run networks)... -> Last Will and Testament
- Continuous session awareness -> Last Will and Testament
- Expect that client applications may have very limited processing resources available.
- Provide traditional messaging qualities of service where the environment allows. Provide "quality of service"
- Data agnostic. Don't mandate content formats, remain flexible.
MQTT Community Wiki by mqtt.org community members is licensed under a Creative Commons Attribution 4.0 International License and was made possible by the generosity of all of its contributors.