MQTT (Message Queue Telemetry Transport)
Presentations:
Aticles:
[Introduction]
- History
1999년 Dr. Andy Stanford-Clark(IBM)와 Arlen Nipper of Arcom (Cirrus Link Solution)에 의해 만들어짐
2010년 royalty-free license로 publish됨.
2013년 5월 M2M telemetry data communication으로 OASIS 표준화 작업 시작.
2010년 royalty-free license로 publish됨.
2013년 5월 M2M telemetry data communication으로 OASIS 표준화 작업 시작.
아래에서 보겠지만 간략한 format의 protocol로 인해 M2M의 protocol로 자리매김 한 것으로 보임. 하지만 이 프로토콜이 자연스럽게 IOT 영역에서도 받아지는 분위기인지는 잘 모르겠음 워낙 다들 자신들이 IOT의 시작이라 외치니..
- A lightweight network protocol used for publish/subscribe messaging between devices.
- MQTT is designed to be open, simple and easy to implement, allowing thousands of lightweight clients to be supported by a single server.
: ideal for use in constrained environments or low-bandwidth networks with limited processing capabilities, small memory capacities and high latency
: The MQTT design minimizes network bandwidth requirements while attempting to ensure reliability of delivery.
[MQTT Design Principles and Assumptions]
아래 굵은 글씨들이 특징들이겠지만 위에서 말했다시피 low-bandwidth/low performanced device에서의 사용성과 high latency 가 핵심이다.
1. Simplicity, simplicity, simplicity!
2. Publish/subscribe messaging.
3. Zero administration (or as close as possible). Behave sensibly in response to unexpected actions and enable applications to “just work”
4. Minimize the on-the-wire footprint.
5. Expect and cater for frequent network disruption (for low bandwidth, high latency, unreliable, high cost-to-run networks)… → Last Will and Testament
6. Continuous session awareness → Last Will and Testament
7. Expect that client applications may have very limited processing resources available.
8. Provide traditional messaging qualities of service where the environment allows.
9. Data agnostic. Don't mandate content formats, remain flexible.
[Specification]
* specification 보면 protocol 설계 자체가 bit 단위다.. 경량화될 수 밖에..
- Fixed header
- 주요 Message Type 별 header
CONNECT
CONNACK
PUBLISH
SUBSCRIBE
UNSUBSCRIBE
PINGREQ
PINGRESP
DISCONNECT
[Quality of Service]
나름대로 간단한 방식의 QoS rule로 message delivery 방법을 지정하고 전달을 guarantee 하게 할 수 있다.
- QoS 0 - At most once delivery
: 한번 전달 하고 마는 방식으로 시간, packet 사용량은 적으나 메세지 전달은 guarantee 할 수 없음.
: 한번 전달 하고 마는 방식으로 시간, packet 사용량은 적으나 메세지 전달은 guarantee 할 수 없음.
* deliver the message once, with no confirmation.
: A response is not expected and no retry semantics are defined in the protocol.
: This is the least level of Quality of Service and from a performance perspective, adds value as it’s the fastest way to send a message using MQTT.
: A QoS 0 message can get lost if the client unexpectedly disconnects or if the server fails.
The table below shows the QoS level 0 protocol flow.
| Client | Message and direction | Server |
|---|---|---|
| QoS = 0 | PUBLISH----------> | Action: Publish message to subscribers |
- QoS 1 - At least Once Delivery
: 메세지 전달 후 server에서 수신확인 메세지를 받아 처리하는 방식으로 메세지 전달 여부는 확인 가능.
: 메세지 전달 후 server에서 수신확인 메세지를 받아 처리하는 방식으로 메세지 전달 여부는 확인 가능.
* deliver the message at least once, with confirmation required.
: For this level of service, the MQTT client or the server would attempt to deliver the message at-least once. But there can be a duplicate message.
The table below shows the QoS level 1 protocol flow.
| Client | Message and direction | Server |
|---|---|---|
| QoS = 1 DUP = 0 Message ID = x
Action: Store message
| PUBLISH----------> | Actions:
|
| Action: Discard message | PUBACK<---------- |
- QoS 2 - Exactly once delivery
: 메세지 전달(publish), 수신 확인, 메세지 삭제, 메시지 전달 완료의 절차로 message 전달(publish)을 확인하는 거침으로 메세지 전달을 최대한 guarantee함.
* deliver the message exactly once by using a four step handshake
* deliver the message exactly once by using a four step handshake
: This is the highest level of Quality of Service.
: Additional protocol flows ensure that duplicate messages are not delivered to the receiving application. The message is delivered once and only once when QoS 2 is used.
| Client | Message and direction | Server |
|---|---|---|
| QoS = 2 DUP = 0 Message ID = x
Action: Store message
| PUBLISH----------> | Action: Store message
or
Actions:
|
PUBREC<---------- | Message ID = x | |
| Message ID = x | PUBREL----------> | Actions:
or
Action: Delete message ID |
| Action: Discard message | PUBCOMP<---------- | Message ID = x |
[Topic]
* UTF-8 encoded string
* 모든 MQTT Message는 topic 기반으로 publish되며 별도 설정 방법이 필요하지 않고 message를 publish하는 것으로 topic 설정
* topic들은 계층형 구조를 가질 수 있으며 topic level separator(/)를 통해서 계층이 구분되어 진다.
ex) sensors/COMPUTER_NAME/temperature/HARDDRIVE_NAME
* client들은 subscriptions을 생성하여 message를 전달 받을 수 있고 특정 topic을 선택할 수도 wildcards(+, #)를 사용해서 다수 topic들에 대해서 subscriptions을 생성할 수 있다.
* topic 관련하여 MQTT specification에서 설명하는 rule은 다음과 같다.
= Topic semantics and usage
When you build an application, the design of the topic tree should take into account the
following principles of topic name syntax and semantics:
- A topic must be at least one character long.
- Topic names are case sensitive. For example, ACCOUNTS and Accounts are two different topics.
- Topic names can include the space character. For example, Accounts payable is a valid topic.
- A leading "/" creates a distinct topic. For example, /finance is different from finance. /finance matches "+/+" and "/+", but not "+".
- Do not include the null character (Unicode \x0000) in any topic.
The following principles apply to the construction and content of a topic tree:
- The length is limited to 64k but within that there are no limits to the number of levels in a topic tree.
- There can be any number of root nodes; that is, there can be any number of topic trees.
= Appendix A - Topic wildcards
- Topic level separator (/)
- Multi-level wildcard
: The number sign (#) is a wildcard character that matches any number of levels within a topic
. finance/stock/ibm/#
=> (O) finance/stock/ibm
=> (O) finance/stock/ibm/closingprice
=> (O) finance/stock/ibm/currentprice
=> (O) finance/stock/ibm/currentprice/test
. The Multi-level wildcard(#) can be specified only on its own or next to the topic level separator(/)
=> (O) #
=> (O) finance/#
=> (X) finance#
. The Multi-level wildcard(#) must be the last character used within the topic tree
=> (O) finance/#
=> (X) finance/#/closingprice
. finance/# == finance
- single-level wildcard
: The plus sign (+) is a wildcard character that matches only one topic level.
. finance/stock/+
=> (O) matches finance/stock/ibm
=> (O) finance/stock/xyz
=> (X) finance/stock/ibm/closingprice
. The single-level wildcard(+) must be used next to the topic level separator(/)
=> (O) finance/+
=> (O) finance/+/ibm
=> (X) finance+
. finance/+ != finance
* Topic에 대한 간단한 설명
[MQTT realted software]
Capabilities
| Server | QoS 0 | QoS 1 | QoS 2 | auth | bridge | $SYS | SSL | dynamic topics |
|---|---|---|---|---|---|---|---|---|
| Mosquitto | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| RSMB | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✘ | ✔ |
| WebSphere MQ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Apache Apollo | ✔ | ✔ | ✔ | ✔ | ✘ | ✘ | ✔ | ✔ |
| Apache ActiveMQ | ✔ | ✔ | ✔ | ? | ? | ? | ? | ? |
| webMethods Nirvana Messaging | ✔ | ✔ | ✔ | § | ✘ | ✘ | ✔ | ✘ |
| RabbitMQ | ✔ | ✔ | ✘ | ✔ | ✘ | ✘ | ✔ | ✔ |
| MQTT.js | ✔ | ✔ | ✔ | § | ✘ | ✘ | ✘ | ✔ |
| moquette | ✔ | ✔ | ✘ | ? | ? | ? | ? | ? |
Key: ✔ supported ✘ not supported ? unknown § see limitations
[Examples of MQTT Usage]
관련 기사
댓글 없음:
댓글 쓰기