Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Clone this wiki locally
Principles and Assumptions
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.