Untuk memulai topik kali ini, sebaiknya kita pahami istilah Pub/Sub yg merupakan istilah kirim terima pesan / data dimana dimungkinkan berkomunikasi secara asinkronous, dengan latensi pada orde 100 milidetik.
Pub/Sub pada skala lebih besar di environment cloud semacam youtube digunakan untuk analitik streaming dan jalur integrasi data untuk menyerap dan mendistribusikan data. Ini sama efektifnya dengan middleware berorientasi pesan untuk integrasi layanan atau sebagai jalur antrian untuk memparalelkan tugas.
Pub/Sub memungkinkan membuat sistem "event" atau kejadian antara "Produsen" dan "Konsumen", yang disebut Publisher dan Subscriber. Publisher berkomunikasi dengan Subscriber secara asinkron dengan mem-"broadcast" pesan dari suatu kejadian /event, bukan dengan pesan remote antar satu persatu bagian atau synchronous remote procedure calls (RPCs).
Publisher mengirim pesan kejadian/event ke layanan Pub/Sub, tanpa memperhatikan bagaimana atau kapan event ini akan diproses. Pub/Sub kemudian mengirimkan event ke semua Subscriber yang perlu bereaksi terhadapnya. Dibandingkan dengan sistem yang berkomunikasi melalui RPC, di mana penerbit harus menunggu pelanggan menerima data, integrasi asinkron semacam ini meningkatkan fleksibilitas dan ketahanan sistem secara keseluruhan.
Dalam Pengiriman pesan diperlukan TOPIK sebagai tujuan dimana publisher mengirim pesan, secara asinkron topik ini juga di "subscribe / langganan" oleh pengguna datanya. Mirip seperti chatting melalui IRC atau group email millist jaman dulu dan memang benar, salah satu ide PUB/SUB memang dari aktivitas chatting melalui protokol XMPP. Ini berarti diperlukan suatu "Broker" sebagai pengatur jalannya pesan dan relay storage sementara yg berada diposisi layaknya Cloud. Salah satu protokol pesan PUB/SUB paling ramai digunakan saat ini adalah MQTT.
Protokol MQTT adalah standar de-facto untuk pesan IoT. Distandarisasi oleh OASIS dan ISO, protokol publish/subscribe MQTT menyediakan cara yang terukur dan andal untuk menghubungkan perangkat melalui Internet. Saat ini, MQTT digunakan oleh banyak perusahaan untuk menghubungkan jutaan perangkat ke Internet.
Klien MQTT memublikasikan pesan ke broker MQTT dan klien MQTT lainnya berlangganan pesan yang ingin mereka terima. Implementasi klien MQTT biasanya memerlukan footprint minimal sehingga sangat cocok untuk diterapkan pada perangkat kecil yang dibatasi dan sangat efisien dalam kebutuhan bandwidth mereka.
Broker MQTT menerima pesan yang dipublikasikan dan mengirimkan pesan ke klien MQTT yang berlangganan. Pesan MQTT berisi topik pesan yang menjadi langganan klien MQTT dan pialang MQTT menggunakan daftar langganan ini untuk menentukan klien MQTT untuk menerima pesan.
Kali ini kita gunakan broker HiveMQ yg menawarkan broker MQTT komersial dan open source. Karena kemudahannya maka menjadi rujukan umum bagi merkea yg belajar perpesanan IOT. Kalui ini kita akan mencoba PUB SUB pesan melalui broker ini menggunakan applikasi di PC yaitu : MQTT Explorer ( https://mqtt-explorer.com/ ) dan aplikasi di HP android : IOTMQTTPanel.
Kita akan terhubung dengan broker gratis dari HiveMq dengan alamat broker :
- Adress : broker.hivemq.com
- port : 1883
Kosongkan semua credensial username dan password bahkan certificate pun tidak diperlukan. Kali ini kita akan PUB ke topik : /e38/hello dan SUB ke topik :/e38/halo , untuk itu kita SUB dulu pada MQTTExplorer pada menu advance.
Pada sisi Smartphone Android / Iphone bisa gunakan MQTT browser lainnya, namun untuk kelanjutan project IOT maka diharapkan menginstall IOTMQTTPanel yg lumayan lengkap fasilitasnya. Setting koneksinya seperti berikut :
Hasil dari chatting antara PC dan HP melalui broker HiveMQ dengan protokol MQTT sebagai berikut :
Dengan memahami proses diatas, maka diharapkan ada sedikit gamaran mengenai konsep PUB SUB melalui protokol MQTT, dan selanjutnya bisa kirim terima data sensor ke smartphone.
MQTT menerapkan 3 tingkat kualitas layanan untuk kesepakatan antara pengirim dan penerima: 1) Paling banyak satu kali (0), 2) Setidaknya satu kali (1), dan 3) Tepat sekali (2). Level QoS ini memungkinkan aplikasi IoT yang lebih andal karena infrastruktur perpesanan yang mendasarinya dan beradaptasi dengan kondisi jaringan yang (mungkin) tidak dapat diandalkan.
MQTT memungkinkan sesi persisten antara klien dan broker. Ini memungkinkan sesi tetap ada meskipun jaringan terputus. Setelah jaringan terhubung kembali, informasi untuk menghubungkan kembali klien ke broker masih ada. Ini adalah salah satu fitur utama yang membuat protokol MQTT lebih efisien daripada HTTP untuk digunakan melalui jaringan seluler yang (mungkin) tidak dapat diandalkan.
Klien MQTT yang Subscribe topik baru tidak memiliki wawasan tentang kapan harus mengharapkan pesan pertama yang akan mereka terima. Namun, broker MQTT dapat menyimpan pesan yang disimpan yang dapat segera dikirim setelah berlangganan MQTT baru. Dalam hal ini, klien MQTT akan menerima setidaknya satu pesan setelah Subscribe topik.
Klien MQTT dapat menentukan pesan kepada broker MQTT, yang disebut wasiat terakhir, yang akan dikirim jika klien MQTT terputus secara tidak wajar. Hal ini memungkinkan untuk pemberitahuan seluruh sistem yang lebih anggun bahwa klien telah terputus.
Jangan lupa lanjutannya di part 5 ya ===> KLIK DISINI
0 komentar:
Posting Komentar