Menggunakan Protokol MQTT (Bagian I)

Protokol MQTT

Protokol MQTT (Message Queue Telemetry Transport) merupakan mekanisme “antrian pesan” yang menggunakan prinsip publish & subscribe. Dalam pengiriman data, penggunaan protokol MQTT tidak terlepas dari publisher, subscriber dan broker. Publisher mengirimkan pesan / data kepada semua client yang telah terdaftar pada suatu topic (subscriber) melalui sebuah broker (MQTT Server). MQTT dibuat dan digunakan IBM untuk komunikasi mechine-to-mechine dan pada tahun 2013 IBM mengirimkan standard MQTT versi 3.1 ke OASIS. Yaitu konsorsium non-profit yang menangani standardisasi pengembangan IoT, energi, emergency management dan bidang lainnya.

MQTT Broker
Relasi publisher – broker – subscriber

Dalam MQTT Protokol beberapa client terhubung ke sebuah broker dan “berlangganan” suatu topic yang mereka inginkan untuk mereka “dengar”. Beberapa client yang terhubung juga dapat mempublikasikan pesan atau data dengan topic tertentu. Sebuah client dapat juga berlangganan beberapa topic sekaligus dan beberapa client dapat berlangganan topic yang sama.

Jika client mempublikasikan suatu topic maka beberapa client lain dapat menerima pesan tersebut secara simultan untuk berbagai tujuan. Client dapat berupa service di sebuah server, suatu aplikasi android/iOS, aplikasi desktop atau bahkan service di sebuah microcontroller. Sehingga protokol MQTT populer dalam dunia IoT.

Topic dituliskan secara hierarki dengan menggunakan “/” sebagai pemisah, hal tersebut dapat mempermudah untuk pengaturan dan separasi data. Contoh penulisan topic:

“sensor/jakarta/rumah/temperatur/ruangtamu”

sebuah client bisa menerima data MQTT dengan berlangganan pada sebuah topic. Sebuah topic dapat ditulis secara eksplisit sebagaimana contoh diatas atau dengan menyertakan wildcard dalam penulisan berupa simbol “+” dan “#”.

Simbol “+” digunakan untuk meringkas 1 level hierarki dalam penulisan sebuah topic, contoh:

“sensor/jakarta/+/temperatur/+”

Contoh lain, misalkan diberikan topic sebagai berikut “a/b/c/d”, penulisan wildcard “+” yang benar adalah sebagai berikut:

  • +/b/c/d
  • a/+/c/d
  • a/+/+/d
  • +/+/+/+

Simbol “#” digunakan untuk meringkas topic level hierarki dibawahnya. Misal diberikan kembali topic “a/b/c/d” dan penulisan wildcard “#” yang benar adalah :

  • #
  • a/#
  • a/b/c/#
  • +/b/c/#
  • a/+/c/#

Dalam MQTT terdapat 3 level Quality of Service (QoS). Level QoS menggambarkan seberapa “ketat” broker/client memastikan data / pesan dapat tersampaikan dengan baik. Pesan dapat dikirim menggunakan 3 level QoS begitu juga dalam penerimaan data / pesan oleh dan dari suatu client.

Ketika publisher mem-broadcast sebuah topic dengan QoS 2 dan subscriber1 berlevel QoS 0, maka pesan akan disampaikan dengan level QoS 0. Tetapi ketika subscriber2 menggunakan QoS 2, maka pesan akan disampaikan berlevel QoS 2 meski pesan yang diterima sama dengan subscriber1.

MQTT Protocol
Alur komunikasi Publisher – Broker – Subscriber

Makin tinggi level QoS maka data akan semakin reliable. Dengan kata lain performa kualitas data semakin baik namun latensi akan semakin tinggi dan memerlukan bandwidth yang lebih prima.

QoS 0 : Broker / Client akan mengirim pesan hanya sekali tanpa konfirmasi.

QoS 1: Broker / Client akan mengirim pesan minimal sekali dengan konfirmasi.

QoS 2: Broker / Client akan mengirim pesan hanya sekali dengan menggunakan 4 langkah handshake.

Selain Quality of Service, MQTT memiliki fitur untuk Retain Message. Yaitu kemampuan broker dalam menyimpan atau mempertahankan pesan sekalipun pesan tersebut telah dikirimkan ke seluruh client / subscriber. Ketika ada client yang baru berlangganan/subscription dari suatu topic maka pesan yang disimpan tersebut akan segera dikirimkan oleh broker. Keuntungan adanya retain message, client dapat memperoleh update pesan lebih cepat. Dimana Jika client berlangganan topic yang tidak terlalu sering di-publish.

Ketika koneksi terhubung antara client dengan broker, client dapat men-set clean session flag atau dikenal juga dengan clean start flag. Jika clean session di set “false” maka ketika client tidak terhubung dengan broker. Semua pesan subscription client yang ber-QoS 1 dan QoS 2 akan disimpan dan dikirmkan segera setelah client terkoneksi kembali.

Ketika client terhubung dengan sebuah broker, dimungkinkan ada informasi bahwa broker memiliki pesan “will“. Pesan tersebut berisi bahwa broker akan mengirimkan suatu pesan “darurat” ketika koneksi client dengan broker terputus. Pesan “will” ini memiliki topic, QoS dan status retain sebagaimana data pada pesan MQTT.

supported by rumahiot

Beben

Technology enthusiast.

Mungkin Anda juga menyukai

1 Respon

  1. 11 Juli 2020

    […] data posisi menggunakan protokol MQTT melalui […]

  2. 23 Juli 2020

    […] MQTT, API server, […]

Tinggalkan Balasan

Situs ini menggunakan Akismet untuk mengurangi spam. Pelajari bagaimana data komentar Anda diproses.