2014年1月26日

MQTT(一)簡介

前言

會知道MQTT協定,要先回憶起兩年前,當初想找找Android的Push Notification的解決方案,先是找到了當時GCM的前身C2DM,以為Google已經提供了此服務,測試了一下code也蠻容易上手的,結果發現到他有quota限制,不適合拿來當成產品,因此就放棄它,改找別的解決方案,最後找到了兩種不同的實作方式,一種透過XMPP協定來完成,另一種也就是今天要提到的,透過MQTT來完成。

所以MQTT是什麼?

MQTT的全名為 Message Queuing Telemetry Transport,為IBM和Eurotech共同製定出來的protocol,在MQTT的官網可以看到一開始它對MQTT的介紹:
MQTT is a machine-to-machine (M2M)/"Internet of Things" connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport.
簡單來說,它是為了物聯網而設計的protocol,並且它是透過publish/subscribe的方式來做訊息傳送。由於是為了物聯網而設計的協定,因此它所需要的網路頻寬是很低的,而所需要的硬體資源也是低的。

Publish/Subscribe:

在看MQTT之前,最好要先知道Publish/Subscribe的訊息傳送機制為何,這樣之後在看其協定時,才會更快上手。Publish/Subscribe有三種主要的組成元件,分別為Publisher、Subscriber以及Topic。

Publisher為訊息的來源,它會將訊息發送給Topic,而Subscriber向Topic註冊,表示他們想要接收此Topic的訊息;因此當有某個Publisher對Topic發送訊息時,只要是有對此Topic註冊的Subscriber,都會收到此則訊息。
它們的關係如下圖:


MQTT特性:

了解了Publish/Subscribe的機制之後,讓我們來看看MQTT有哪些特性:
  1. Publish/Subscribe的訊息傳送模式,來提供一對多的訊息分配。
  2. 使用TCP/IP來提供基本的網路連結。
  3. 三種訊息傳送服務的qualities:
    • "At most once",最多一次,訊息遺失或是重複發送的狀況可能會發生;這種quality適合應用在環境感測,不在意資料是否會遺失,因為下一次的資料取樣很快就會被published出來。
    • "At least once",至少一次,這種quality保證訊息會送達,只是可能會發生重複發送訊息的狀況。
    • "Exactly once",確定一次,確認訊息只會送到一次。這種quality適合用在計費系統,系統只要有重複收到資料、或是資料遺失狀況發生,就會造成系統錯誤。
  4. 由於他的header固定長度為2byte,因此可以減少封包傳送時的額外負載,並減少所需的網路頻寬。
  5. 當異常斷線發生時,會使用最後遺囑(Last Will and Testament)的機制,通知各個感興趣的client。

MQTT現況:

MQTT現階段並不是一個標準化的Protocol,還在持續改進中,目前為MQTT V3.1。不過IBM已於2013年已經將它交給OASIS進行標準化了,並且一直以來IBM對此協定採開放、免授權費的方式讓它能夠被散佈,因此相信不久的將來會成為一個主流的Protocol。

而目前支援MQTT的Client API,有Eclipse Phno Project有對MQTT client支援,其支援C、Java、Javascript、C++等等的語言,可說是支援度很高的Project。而目已經在應用MQTT的,最知名的應該就是Facebook Message App了吧,可以參考此篇文章文章

小結:

上面提到的,低頻寬、低硬體需求的特性,訊息傳遞為Publish/Subscribe的方式,正好可以用來實現Push Notification的機制,並且能達到手持裝置省電的需求,接下來會先從其Protocol開始了解,並用Client Api跑些範例來應用此Protocol。

參考:

MQTT v3.1 specification