25 Tahun MQTT

 (andypiper.co.uk)
4 poin oleh GN⁺ 2024-10-23 | 1 komentar | Bagikan ke WhatsApp
  • MQTT telah menyebar selama 25 tahun sejak spesifikasi pertamanya dipublikasikan pada Oktober 1999, dari protokol ringan untuk perangkat kecil dan jaringan yang tidak stabil ke berbagai bidang industri, rumah, dan aplikasi
  • Struktur publish/subscribe yang sederhana, yang mengasumsikan daya terbatas dan koneksi intermiten, tetap menjadi kekuatan bahkan setelah lingkungan jaringan dan perangkat edge berubah
  • MQTT yang dulu digunakan di sekitar IBM mulai menyebar luas di komunitas pada 2009–2011, lalu melalui Mosquitto dan Eclipse Paho berkembang menjadi ekosistem protokol terbuka di luar IBM
  • Kini MQTT hadir juga di tempat yang tidak disadari pengguna, seperti pemrosesan pesan Raspberry Pi berbasis Node-RED, pembersih udara Dyson dan aplikasinya, kontrol printer 3D, notifikasi rumah, serta lokasi manufaktur
  • Menjelang ulang tahun ke-25, komunitas berpindah dari akun proyek lama di X ke @mqtt@fosstodon.org di Mastodon, dan juga memposting pesan pertamanya ke Fediverse berbasis ActivityPub

Perpesanan ringan yang berawal dari lingkungan terbatas

  • Oktober 2024 menandai 25 tahun sejak dokumen yang menjadi spesifikasi pertama MQTT dipublikasikan
  • MQTT adalah protokol jaringan yang dirancang dengan asumsi perangkat kecil dan terbatas, serta jaringan yang ringan atau tidak stabil pada akhir 1990-an
  • Fokusnya adalah mengirim data sensor ke sistem yang lebih besar dalam situasi dengan koneksi intermiten dan daya terbatas, seperti perangkat pemantauan lingkungan jarak jauh
    • Perangkat seperti ini harus menghemat daya, bandwidth, dan ketersediaan jaringan
    • MQTT cocok untuk cara memublikasikan, mengumpulkan, dan menerima data dalam format yang kecil tetapi berguna
  • Bahkan setelah jaringan menjadi lebih cepat dan stabil, serta perangkat edge, otomasi rumah, dan perangkat portabel bertambah banyak, kesederhanaan protokol tetap menjadi kekuatan utama MQTT

Meluas dari sekitar IBM ke ekosistem terbuka

  • Setelah bergabung dengan IBM pada 2001, ia mengerjakan proyek pelanggan terkait IBM MQ, integrasi bisnis, message queueing, koneksi aplikasi, dan middleware
  • IBM Hursley Lab adalah basis MQ sekaligus tempat aktivitas Andy Stanford-Clark, salah satu pencipta MQTT, dan eksperimen MQTT dimulai di sekitarnya
  • Saat itu MQTT sudah dipublikasikan secara eksternal sebagai protokol, tetapi belum banyak dikenal atau diimplementasikan secara luas di luar IBM
  • Sekitar 2009–2011, upaya memperkenalkan MQTT ke luar cakupan implementasi kecil IBM mulai berkembang
    • Saat itu pilihan broker mencakup IBM WebSphere Message Broker yang bersifat enterprise dan mahal, microbroker closed source, serta Really Small Message Broker yang closed source tetapi tersedia gratis
    • Mosquitto, open source buatan Roger Light, masih menjadi salah satu implementasi gratis yang banyak digunakan hingga kini
    • Roger Light membuat Mosquitto setelah mendengar presentasi Andy Stanford-Clark tentang smart home yang terhubung di OggCamp pertama pada 2009, 10 tahun setelah tanggal pembuatan spesifikasinya

Eclipse Paho dan standardisasi resmi

  • Pada 2011, implementasi MQTT IBM didonasikan ke komunitas Eclipse dan proyek Eclipse Paho dimulai
  • Setelah meninggalkan IBM pada 2012, hubungan dengan proyek Paho tetap berlanjut, dan ia juga memegang peran saat bekerja di Cloud Foundry
  • Setelah bergabung dengan Twitter pada 2014, ia mundur dari keterlibatan resmi
  • Pada periode itu, MQTT menjalani proses standardisasi resmi di OASIS dan ISO/IEC

MQTT di tempat-tempat yang tak terlihat saat ini

  • MQTT telah melampaui batas IBM dan menjadi contoh sukses protokol terbuka; 25 tahun kemudian, ia hadir di berbagai produk dan tempat yang tidak disadari pengguna
  • Contoh penggunaan utamanya antara lain
    • Proyek pengembang hobi dan maker
    • Pembersih udara Dyson dan aplikasi terkait
    • Sistem kontrol printer 3D
    • Sistem notifikasi rumah
    • Lingkungan industri dan manufaktur
  • Di ruang kerja pribadi pun MQTT digunakan dalam berbagai cara
    • Printer 3D Bambu Lab X1C menggunakan MQTT untuk komunikasi internal
    • Perangkat terhubung di dinding merespons notifikasi MQTT untuk menampilkan data atau menyalakan lampu
    • Node-RED yang berjalan di Raspberry Pi memproses pesan MQTT
  • Sangat mungkin setidaknya salah satu aplikasi di ponsel saat ini menggunakan MQTT di suatu bagian stack-nya

Ulang tahun ke-25 dan perpindahan komunitas

  • Akun komunitas MQTT berpindah ke Mastodon, menggantikan akun proyek lama di X
  • Akun baru dapat diikuti di @mqtt@fosstodon.org
  • Untuk memperingati ulang tahun ke-25, MQTT bergabung dengan open social web dengan memposting pesan pertamanya ke Fediverse melalui ActivityPub
  • Andy Stanford-Clark mengadakan fireside chat dengan HiveMQ, dan podcast HiveMQ The Unstructured Message juga diperkenalkan sebagai tempat untuk melihat lebih banyak konten terkait MQTT

Bacaan terkait

1 komentar

 
GN⁺ 2024-10-23
Pendapat di Hacker News

  • Proyek pertama yang masih beroperasi dan dipakai setiap hari adalah mengambil peta SVG sistem air pipa/pompa/katup untuk pembuatan salju dan pemadaman kebakaran di sebuah resor ski besar, lalu menjadikannya situs web penampil status
    Untuk tiap pompa, katup, dan segmen pipa dibuat topik MQTT, lalu diberi status seperti arah aliran air, pompa/katup nyala-mati, dan tekanan; warna serta isian SVG diperbarui dengan mqtt.js dan jQuery
    Broker MQTT yang dijalankan sebagai container di hosting statis sudah hampir 10 tahun berjalan tanpa disentuh, dan mqtt.js bekerja di atas WebSocket sehingga ketika status berubah, semuanya otomatis tercermin ke semua orang

    • Mengejutkan bahwa Docker ternyata sudah menjadi teknologi berusia 11 tahun

  • Pernah memakai MQTT di proyek terbaru, tetapi tidak terlalu menyukainya
    Protokolnya punya banyak opsi, dan sulit untuk langsung memahami apa fungsi tiap opsi, mengapa penting, serta kombinasi mana yang harus dipakai agar bekerja sesuai niat; dokumentasinya juga tidak terlalu membantu menjelaskan hal itu
    Sebagian mungkin karena klien Python Eclipse Mosquitto yang dipakai; di sistem yang lambat terjadi race condition sehingga langganan topik diam-diam diabaikan dan callback rusak, dan butuh beberapa hari untuk mengetahuinya
    Padahal dokumentasi sudah diikuti 100%, dan untuk protokol yang belum terlalu tua, itu salah satu pengalaman paling berantakan

    • Di sini sepertinya kliennya saja yang kurang bagus
      Pengalaman memakai klien-klien Eclipse, misalnya Paho di Python dan C++, juga mirip: terlalu rumit, terasa terlalu low-level, dan karena strukturnya ada beberapa bug
      Mungkin ini terjadi seiring waktu karena pemeliharaannya hampir setingkat satu orang saja. Klien C++ pun dalam 6 bulan terakhir hanya punya satu kontributor, dan 3 bulan terakhir tidak ada yang berkontribusi
      PR sederhana untuk memperbaiki bug yang jelas, bahkan sekadar mengubah satu kata, butuh 2 tahun sampai direview dan digabung. Ini bukan bermaksud menyalahkan, melainkan terlihat seperti ada banyak library, bug, dan pekerjaan yang ditangani oleh segelintir orang yang kelelahan
      Setelah pindah ke klien lain, pengalaman di Python, Rust, C#, dan C++ jauh lebih baik; kebanyakan punya kombinasi API high-level dan low-level yang bagus, sehingga jika hanya ingin mengirim pesan ke topik, tidak perlu memikirkan acknowledgment atau retry
      Sebaliknya, kalau butuh kontrol, kontrol itu juga tersedia. Saya khawatir mempertahankan paho dan semacamnya dalam kondisi sekarang justru merugikan. Kalau secara resmi sudah mati, setidaknya masalahnya akan dipaksa muncul ke permukaan; sekarang pengguna mengalami hal seperti ini lalu menyerah pada MQTT atau merasa dirinya yang salah
    • Saya sudah memakai MQTT dengan library MQTT paho Python dan memang membuat cukup banyak hal, tetapi secara keseluruhan pengalamannya mengerikan
      Desain API, dokumentasi yang minim, sampai cara kerjanya yang terasa tidak mengikuti konvensi Python, semuanya mengganggu
      Awalnya tampak mudah, tetapi luasnya protokol dan implementasi lama-kelamaan menghambat. Pernah suatu saat cara yang andal untuk memastikan apakah sudah berhasil terhubung ke server adalah mencoba berlangganan topik yang sama dua kali lalu menangkap kode error tertentu dari pesan on_connect. Saat itu kode tersebut di dokumentasi disebut sebagai kode sukses
      Saya tahu ini terdengar tidak masuk akal, tetapi walaupun ada cara yang lebih baik, cara itu tidak mudah ditemukan. Meski begitu, mengeluh memang mudah, dan saya berterima kasih kepada banyak orang yang membuat library ini. Tanpa mereka saya tidak akan bisa membuat apa yang sudah saya buat, dan saya menghormati orang-orang yang mengambil tanggung jawab atas proyek sebesar ini
    • Saya pernah memakai Paho API di Python, C, dan C++, tetapi akhirnya semuanya tidak lagi saya pakai
      Jika memungkinkan, saya memilih menangani protokol dengan mosquitto_sub dan mosquitto_pub, lalu hanya membaca dan menulis lewat input/output standar
      Bukan semata karena bug, tetapi lebih mudah menyerahkan pengelolaan koneksi broker kepada program yang sudah ditulis dan diuji
      Namun untuk will message cara ini tidak bisa saya pakai secara efektif, dan juga tidak cocok untuk mikrokontroler yang tidak menjalankan sesuatu seperti Linux
    • Meski bukan pesaing langsung MQTT, https://pipe.pico.sh adalah alat publish/subscribe yang hebat untuk berkomunikasi lewat SSH
      Pada dasarnya ini membuat sistem pipe jaringan *nix yang terautentikasi, dengan tujuan menjadi cara paling sederhana untuk mengirim dan menerima event
    • Saya pernah melihat komentar seperti “kenapa tidak pakai TCP saja”, dan untuk proyek IoT saya, TCP biasa sudah cukup
      Dalam use case saya, antrean tak terbatas itu penting, tetapi MQTT tidak menyediakannya; kalau saya tetap harus mengelola ID pesan sendiri agar MQTT melacak ID pesannya sendiri dan mengirimkannya ke broker, tidak ada alasan kuat untuk memakainya
      Kalau bukan untuk berintegrasi dengan proyek yang sudah disesuaikan dengan MQTT, saya tidak begitu tahu penggunaan optimalnya apa

  • Dalam beberapa tahun terakhir, MQTT makin banyak digunakan di dalam pabrik untuk berbagi data antarmesin
    Secara historis, MQTT digunakan di bidang Oil & Gas untuk SCADA yang mengambil data dari lokasi sumur minyak jarak jauh
    Lebih dari 10 tahun lalu, saya menambahkan MQTT ke Kepware (server OPC) untuk melakukan streaming nilai tag ke “cloud”; setelah presentasi, Arlen Nipper, salah satu pencipta MQTT, datang dan berkata “lumayan bagus,” yang membuat saya merasa rendah hati
    Sekarang, di perusahaan baru bernama HighByte, kami memodelkan data pabrik di edge dan mengirimkannya ke MQTT, SparkplugB (protokol di atas MQTT), S3, Azure Blob, dan lainnya
    Singkatnya, MQTT adalah pendorong besar Industry 4.0, dan keren melihatnya masih begitu banyak digunakan setelah sekian lama

    • Saat ini, dengan plugin Kepware IoT, kami melakukan streaming sekitar 800 ribu tag per detik melalui MQTT dan akhirnya memasukkannya ke DB VictoriaMetrics
      Agak kasar dan memiliki lebih banyak tahap pemrosesan daripada yang kami inginkan. Karena Kepware mengenakan biaya lisensi berulang tahunan untuk plugin IoT, kini kami sedang beralih dari solusi itu ke arah telegraf yang membaca data OPC-UA langsung dari Kepware
      Saya penasaran apakah Anda pernah atau masih bekerja di Kepware
    • Saya bekerja di industri yang sama, dan kelemahan teknis, perluasan cakupan, serta sindrom NIH pada standar OPC Foundation cukup membuat bingung
      Saya berharap mereka cukup memakai Sparkplug B saja dan mengimplementasikan spesifikasi untuk semantik di atasnya
      Selain itu, pekerjaan terkait asinkron yang sedang mereka lakukan sekarang juga terlalu over-engineered dan buruk. Saya sempat ikut rapat selama beberapa waktu, dan meski spesifikasi MQTT kurang dari 50 halaman dan mudah dibaca, mereka belum pernah membacanya dan tidak memahami untuk apa header itu. Misalnya, mereka mencoba memasukkan sesuatu ke header padahal seharusnya masuk ke payload
      Seseorang dari pihak Microsoft bahkan tersinggung saat ada usulan untuk melihat dulu apa yang dilakukan para pesaing dengan MQTT. Karena mereka lebih ingin membuat yang baru daripada menyalin
      Atas saran saya, perusahaan kami akan menangani OPC UA hanya di edge paling luar, dan mengisolasinya sejauh mungkin dari teknologi kami
    • Tempat pertama saya melihat MQTT juga di bidang produksi kimia, dan saya juga sering melihatnya di sistem kendali penerbangan dan kereta api
      Namun belakangan ini saya juga melihat Kafka dan RabbitMQ makin banyak masuk ke wilayah pasar MQTT
    • Saya penasaran apakah MQTT kini digunakan di tempat-tempat yang dulu akan memakai Modbus

  • Sekitar 15 tahun lalu, ketika perangkat IoT yang bisa menge-tweet belum umum, rumah Andy Stanford Clark pernah menjadi bahan berita
    https://www.bbc.co.uk/blogs/technology/2009/06/things_that_t...
    Protokol intinya dirancang pada masa ketika mengirim 1 byte lewat tautan satelit berbiaya 1 dolar, sehingga luar biasa efisien dan implementasinya juga sederhana

  • Dulu pernah ada kasus ketika satu-satunya port yang bisa digunakan di firewall seorang klien hanyalah MQTT 1883
    Karena mereka menerima data sensor lewat cara itu, dan seberapa pun kami meminta, mereka tidak mau membuka port lain, jadi kami membuat wrapper TCP real-time di atas MQTT untuk mengakalinya
    Daemon TCP lokal multithread mendengarkan permintaan keluar pada port tertentu, membungkusnya dengan MQTT, lalu mem-publish ke topik unik; daemon server memantau topik itu, membukanya, lalu meneruskannya ke proses server
    Dari sudut pandang mesin klien, itu tampak seperti membuat koneksi TCP real-time ke server kami, tetapi di tengahnya ada wrapper MQTT aneh yang tak terlihat
    Setelah berjalan, hasilnya elegan, tetapi debugging-nya benar-benar menyakitkan, dan butuh berbulan-bulan melewati banyak jalan buntu sampai semuanya benar-benar pas

    • Saya juga pernah bekerja di tempat di mana mengakali aturan firewall seperti ini bisa membuat Anda dipecat
      Sekarang, situasi ketika Anda tidak bisa melakukan apa-apa dan hanya harus diam disebut “membiarkan proses berjalan”
    • Pada dasarnya, itu berarti mengimplementasikan protokol MQTT-Sockets, dan dengan itu semestinya juga bisa terhubung ke server WebSockets di sisi lain

  • Fakta menarik: Boost, library C++ paling terkenal, pada waktu yang sama sedang meninjau apakah akan memasukkan implementasi async-mqtt5 (https://github.com/mireo/async-mqtt5) sebagai Boost.MQTT: https://lists.boost.org/Archives/boost/2024/10/index.php

    • Saya penasaran apakah orang-orang masih memilih Boost untuk proyek baru belakangan ini
      Secara anekdot, sebagian besar adopsinya terjadi pada era 2000-an dan awal sekali 2010-an, sebelum semua orang mewajibkan C++0x/C++11, dan sekarang saya hanya jarang melihatnya
      boost.org terasa seperti perjalanan ke masa lalu. Tampilannya masih persis seperti yang saya ingat sekitar 2008, termasuk tulisan “Get Boost” yang ditempelkan di tombol penghenti darurat

  • MQTT benar-benar protokol kecil yang bagus; tidak hanya “cukup kecil” untuk dipakai pada proyek hobi, tetapi juga mampu diskalakan hingga digunakan untuk hal seperti Facebook Messenger
    [1]: https://engineering.fb.com/2011/08/12/android/building-faceb...

  • Promosi yang menyebut MQTT ringan dan efisien terasa kurang meyakinkan
    Pada akhirnya itu hanya memakai TCP/IP, dan mungkin relatif istimewa menurut standar saat itu, tetapi selain klaim yang terus diulang, saya belum pernah melihat bukti nyata yang mendukung pernyataan tersebut
    Bagus karena sebagai standar, ia bisa terhubung ke perangkat siap pakai yang mendukungnya. Namun untuk publish/subscribe atau antrean pesan, saya melihat ada pilihan yang lebih baik, terutama jika diperlukan failover di sisi konsumen

    • Saya penasaran apa pilihan yang lebih baik itu
      Hal bagus dari MQTT, sekaligus hal yang menurut saya salah pada hampir semua implementasi publish/subscribe lain yang pernah saya lihat, adalah bahwa struktur data inti MQTT bukan antrean dan topik, melainkan klien yang berlangganan
      Karena itu, kita bisa memetakan ruang alamat sebesar apa pun yang diinginkan ke pohon topik. Pohon topik bisa memiliki triliunan endpoint, dan jika mau, bahkan di server embedded pun bisa ada satu endpoint untuk setiap alamat IPv6
      Karena pohon topiknya kaya, langganan bisa dibuat selektif sesuai kebutuhan, dan server tetap bisa berjalan cepat dengan penggunaan sumber daya yang kecil
    • Sungguh, saya penasaran apa alternatif yang lebih baik untuk publish/subscribe dan antrean pesan

  • Saya sudah menggunakan MQTT selama beberapa tahun di kelas IoT, dan terbukti sebagai alat yang sangat serbaguna
    Dukungan melalui WebSocket juga praktis

  • Dalam proyek sistem embedded baru-baru ini, cukup menarik memakai MQTT sebagai sistem messaging antarproses
    Broker dan klien berjalan di mesin yang sama
    Kalau perlu melakukan sniffing atau debugging, cukup sambungkan perangkat ke jaringan lalu rekam atau injeksikan pesan dengan MQTT Explorer, jadi mudah
    Kami juga bisa membuka port ke luar LAN agar rekan kerja yang sedang bekerja jarak jauh dapat mengutak-atik sistem

    • Saya belum banyak melihat penggunaan seperti ini, tetapi tampaknya punya karakteristik yang diinginkan
      Kekhawatiran terbesar saat dipakai sebagai komponen sistem adalah jaminan durabilitas, dan saya tidak terlalu percaya bahwa implementasi broker tidak akan kehilangan data
    • Kami memakai ZeroMQ untuk keperluan ini. Tidak perlu broker
    • Dalam konteks ini, bukankah ZeroMQ bisa menjadi alternatif?