MQTT 25 yaşında

 (andypiper.co.uk)
4 puan yazan GN⁺ 2024-10-23 | 1 yorum | WhatsApp'ta paylaş
  • MQTT, ilk spesifikasyonuna giden belgenin Ekim 1999'da yayımlanmasının ardından 25 yıl içinde, küçük cihazlar ve kararsız ağlar için hafif bir protokolden sanayiye, eve ve uygulamalara yayıldı
  • Sınırlı güç ve kesintili bağlantıyı temel alan basit publish/subscribe yapısı, ağ ve edge cihaz ortamı değiştikten sonra da güçlü yönü olarak kaldı
  • IBM çevresinde kullanılan MQTT, 2009–2011 döneminde toplulukta ciddi biçimde yayılmaya başladı ve Mosquitto ile Eclipse Paho üzerinden IBM dışındaki açık protokol ekosistemine genişledi
  • Bugün Node-RED tabanlı Raspberry Pi mesaj işleme, Dyson hava temizleyicileri ve uygulamaları, 3D yazıcı kontrolü, ev bildirimleri, üretim sahaları gibi kullanıcıların fark etmediği yerlerde de kullanılıyor
    1. yıl vesilesiyle topluluk, X üzerindeki eski proje hesabı yerine Mastodon'daki @mqtt@fosstodon.org hesabına taşındı ve ActivityPub tabanlı Fediverse'e ilk mesajını gönderdi

Sınırlı ortamlardan doğan hafif mesajlaşma

  • Ekim 2024, MQTT için ilk spesifikasyona dönüşecek belgenin yayımlanmasının 25. yılına denk geliyor
  • MQTT, 1990'ların sonlarındaki küçük ve kısıtlı cihazlar ile hafif ya da kararsız ağlar varsayılarak tasarlanmış bir ağ protokolü
  • Odak noktası, uzak çevresel izleme cihazları gibi bağlantının kesintili ve gücün sınırlı olduğu ortamlarda sensör verilerini daha büyük sistemlere göndermekti
    • Bu tür cihazların güç, bant genişliği ve ağ erişilebilirliğini idareli kullanması gerekir
    • MQTT, veriyi küçük ama kullanışlı bir biçimde publish edip toplama ve alma modeline iyi uyuyor
  • Ağlar daha hızlı ve daha kararlı hale geldikten, edge, ev otomasyonu ve taşınabilir cihazlar arttıktan sonra bile protokolün sadeliği, MQTT'nin temel gücü olmaya devam etti

IBM çevresinden açık ekosisteme yayılım

  • 2001'de IBM'e katıldıktan sonra IBM MQ, iş entegrasyonu, mesaj kuyruklama, uygulama bağlantısı ve middleware ile ilgili müşteri projelerinde çalıştı
  • IBM Hursley Lab, MQ'nun temeli ve MQTT'nin ortak yaratıcısı Andy Stanford-Clark'ın faaliyet merkeziydi; MQTT deneyleri de bu çevrede başladı
  • O dönemde MQTT dışarıya bir protokol olarak açılmıştı, ancak IBM dışında pek bilinmiyor veya yaygın biçimde uygulanmıyordu
  • 2009–2011 civarında MQTT'yi IBM'in küçük uygulama alanının dışına tanıtma çabaları hız kazandı
    • O dönemde broker seçenekleri; kurumsal ve pahalı IBM WebSphere Message Broker, kapalı kaynak microbroker ve kapalı kaynak olmasına rağmen ücretsiz sunulan Really Small Message Broker idi
    • Roger Light'ın geliştirdiği açık kaynak Mosquitto, bugün de yaygın kullanılan ücretsiz uygulamalardan biri
    • Roger Light, 2009'daki ilk OggCamp'te Andy Stanford-Clark'ın bağlantılı akıllı ev sunumunu dinledikten sonra Mosquitto'yu geliştirdi; bu da spesifikasyonun oluşturulmasından 10 yıl sonraydı

Eclipse Paho ve resmi standardizasyon

  • 2011'de IBM'in MQTT uygulaması Eclipse topluluğuna bağışlanınca Eclipse Paho projesi başladı
  • 2012'de IBM'den ayrıldıktan sonra da Paho projesiyle bağlantı sürdü; Cloud Foundry döneminde de rol aldı
  • 2014'te Twitter'a katıldıktan sonra resmi katılımından çekildi
  • Bu dönemde MQTT, OASIS ve ISO/IEC bünyesinde resmi standardizasyon sürecinden geçti

Bugün görünmeyen yerlerdeki MQTT

  • MQTT, IBM'in sınırlarını aşarak açık protokol başarısı örneklerinden biri haline geldi ve 25 yıl sonra kullanıcıların fark etmediği pek çok ürün ve yerde bulunuyor
  • Öne çıkan kullanım alanları şunlar:
    • Hobi geliştiriciler ve maker projeleri
    • Dyson hava temizleyicileri ve ilgili uygulamalar
    • 3D yazıcı kontrol sistemleri
    • Ev bildirim sistemleri
    • Sanayi ve üretim sahaları
  • Kişisel çalışma alanında da MQTT çeşitli şekillerde kullanılıyor
    • Bambu Lab X1C 3D yazıcısı dahili iletişim için MQTT kullanıyor
    • Duvardaki bağlı cihazlar MQTT bildirimlerine tepki vererek veri gösteriyor veya ışık yakıyor
    • Raspberry Pi üzerinde çalışan Node-RED MQTT mesajlarını işliyor
  • Şu anda telefonunuzdaki uygulamalardan en az birinin, yığının bir yerinde MQTT kullanıyor olma ihtimali yüksek

25. yıl ve topluluğun taşınması

  • MQTT topluluk hesabı, eski X proje hesabı yerine Mastodon'a taşındı
  • Yeni hesap @mqtt@fosstodon.org adresinden takip edilebiliyor
    1. yılı kutlamak için MQTT, ActivityPub üzerinden Fediverse'e ilk mesajını göndererek open social web'e katıldı
  • Andy Stanford-Clark, HiveMQ ile bir fireside chat gerçekleştirdi; HiveMQ'nun podcast'i The Unstructured Message de MQTT hakkında daha fazlasını görmek için önerilen yerlerden biri olarak anıldı

İlgili okumalar

1 yorum

 
GN⁺ 2024-10-23
Hacker News yorumları

  • Hâlâ çalışır durumda olan ve her gün kullanılan ilk projem, büyük bir kayak merkezinin kar yapma ve yangın söndürme için kullanılan boru/pompa/vana su sistemi SVG haritalarını alıp durum gösteren bir web sitesine dönüştürmekti.
    Her pompa, vana ve boru hattı bölümü için bir MQTT topic oluşturdum; su akış yönü, pompa/vana açık-kapalı durumu, basınç gibi durumları ekledim ve mqtt.js ile jQuery kullanarak SVG renklerini ve dolgularını güncelledim.
    Statik hosting üzerinde container olarak çalıştırılan MQTT broker neredeyse 10 yıldır dokunulmadan çalışıyor; mqtt.js de websocket üzerinde çalıştığı için durum değiştiğinde herkese otomatik olarak yansıyor.

    • Docker’ın şimdiden 11 yıllık bir teknoloji olması şaşırtıcı.

  • Yakın zamandaki bir projede MQTT kullandım ama pek hoşuma gitmedi.
    Protokolde çok fazla seçenek var; her seçeneğin ne yaptığı, neden önemli olduğu ve hangi kombinasyonlarla kullanıldığında beklendiği gibi çalışacağı hemen anlaşılmıyor, dokümantasyon da bunu iyi açıklamıyor.
    Bunun bir kısmı kullandığım Eclipse Mosquitto Python client yüzünden olabilir; yavaş bir sistemde race condition oluşup topic aboneliklerinin sessizce yok sayıldığını ve callback’lerin bozulduğunu anlamam birkaç gün sürdü.
    Dokümantasyonu %100 izlediğim hâlde böyle oldu ve çok da eski olmayan bir protokol için yaşadığım en dağınık deneyimlerden biriydi.

    • Burada sorun muhtemelen client’ın pek iyi olmamasıydı.
      Eclipse client’larıyla, örneğin Paho’yu Python ve C++’ta kullanırken de benzer deneyimler yaşadım; aşırı karmaşık, fazla düşük seviyeli gibi hissettiriyordu ve yapısı nedeniyle bazı bug’lar vardı.
      Muhtemelen neredeyse tek bir kişi tarafından bakımı yapıldığı için zamanla bu hâle gelmiş. C++ client’ında da son 6 ayda yalnızca bir katkıcı vardı, son 3 ayda ise kimse katkıda bulunmamıştı.
      Bariz bir bug’ı düzelten basit bir PR’ın, tek kelime değiştirmek düzeyinde bile olsa, incelenip merge edilmesi 2 yıl sürdü. Bu bir suçlama değil; daha çok kütüphane, bug ve iş yükünün çok olduğu, bunları da aşırı yüklenmiş az sayıda kişinin ele aldığı bir durum gibi görünüyor.
      Başka client’lara geçince Python, Rust, C# ve C++’ta deneyim çok daha iyi hâle geldi; çoğunda yüksek seviyeli ve düşük seviyeli API kombinasyonu iyi olduğu için yalnızca bir topic’e mesaj göndermek istiyorsanız acknowledgment veya retry gibi şeyleri düşünmeniz gerekmiyor.
      Buna karşılık kontrol gerekiyorsa onu da yapabiliyorsunuz. Mevcut hâliyle paho vb. projeleri hayatta tutmanın yarardan çok zarar verip vermediğinden endişe ediyorum. Resmî olarak ölmüş olsaydı en azından sorun zorla görünür olurdu; şimdi ise kullanıcılar bu deneyimi yaşayıp MQTT’den vazgeçiyor ya da hatanın kendilerinde olduğunu düşünüyor.
    • paho Python MQTT kütüphanesi ile MQTT kullandım ve epey şey de yaptım, ama genel olarak berbat bir deneyimdi.
      API tasarımı, zayıf dokümantasyon ve Python geleneklerine uymuyor gibi görünen yaklaşımın hepsi rahatsız ediciydi.
      Başlangıçta kolay görünüyor ama protokolün ve implementasyonun genişliği giderek ayağınıza dolanıyor. Bir dönem sunucuya başarıyla bağlanıp bağlanmadığınızı kontrol etmenin güvenilir yolu, aynı topic’e iki kez abone olmayı deneyip on_connect mesajındaki belirli bir hata kodunu yakalamaktı. O sırada bu kod dokümantasyonda başarı kodu olarak geçiyordu.
      Kulağa saçma geldiğini biliyorum; daha iyi bir yöntem vardıysa bile kolay bulunabilir değildi. Yine de şikâyet etmek kolay; bu kütüphaneyi yapan birçok kişiye minnettarım. Onlar olmasaydı şu anda yaptıklarımı yapamazdım ve böyle dev projeleri üstlenen insanlara saygı duyuyorum.
    • Python, C ve C++’ta Paho API kullandım ama sonunda hepsini kullanmayı bıraktım.
      Mümkün olduğunda protokolü mosquitto_sub ve mosquitto_pub ile ele alıp yalnızca standart girdi/çıktı okumayı ve yazmayı tercih ettim.
      Bunun nedeni yalnızca bug’lar değildi; broker bağlantı yönetimini zaten yazılmış ve test edilmiş bir programa bırakmak daha kolaydı.
      Ancak will message konusunda bu yöntemi etkili kullanamadım ve Linux gibi bir şey çalıştırmayan mikrodenetleyiciler için de uygun değil.
    • MQTT ile doğrudan rekabet etmiyor ama https://pipe.pico.sh SSH üzerinden iletişim kuran harika bir publish/subscribe aracı.
      Fiilen kimliği doğrulanmış ağ üzerinden çalışan bir *nix pipe sistemi oluşturuyor ve olay gönderip almanın en basit yolu olmayı hedefliyor.
    • Bir yerde “Neden sadece TCP kullanmıyoruz?” tarzı bir şey görmüştüm; benim IoT projem için sıradan TCP yeterliydi.
      Benim kullanım senaryomda sınırsız kuyruk önemliydi ama MQTT bunu sağlamıyordu; MQTT’nin kendi mesaj ID’lerini takip edip broker’a göndermesi için bir de benim mesaj ID’leri yönetmem gerekiyorsa kullanmak için pek neden kalmıyordu.
      Zaten MQTT’ye göre tasarlanmış projelerle entegre olmuyorsanız en uygun kullanım alanının ne olduğundan pek emin değilim.

  • Son birkaç yılda MQTT, fabrika içinde makineler arasında veri paylaşımı için çok daha fazla kullanılır oldu
    Tarihsel olarak Oil & Gas alanında, uzak petrol kuyusu sahalarından veri almak için SCADA amaçlı kullanılıyordu
    10 yıldan fazla önce Kepware'e (OPC sunucusu) MQTT ekleyip tag değerlerini “buluta” stream etmiştim; sunumdan sonra MQTT'nin yaratıcılarından Arlen Nipper gelip “fena olmamış” deyince mütevazılaşmıştım
    Şimdi HighByte adlı yeni bir şirkette, edge'de fabrika verilerini modelliyor ve bunları MQTT, SparkplugB (MQTT üzerinde bir protokol), S3, Azure Blob gibi yerlere gönderiyoruz
    Kısacası MQTT, Industry 4.0 için büyük bir itici güç ve bunca zaman geçtikten sonra hâlâ bu kadar çok kullanılması güzel

    • Şu anda Kepware IoT eklentisiyle saniyede yaklaşık 800 bin tag'i MQTT üzerinden stream edip en sonunda VictoriaMetrics DB'ye koyuyoruz
      Biraz kaba saba ve istediğimizden fazla işlem adımı var. Kepware IoT eklentisi için her yıl yinelenen lisans ücreti aldığından, şimdi o çözümden uzaklaşıp telegraf'ın OPC-UA verilerini doğrudan Kepware'den okumasına geçiyoruz
      Kepware'de çalışmış ya da çalışıyor musun merak ettim
    • Aynı sektörde çalışıyorum; OPC Foundation standardının teknik açıdan zayıflığı, kapsam şişmesi ve NIH sendromu oldukça şaşırtıcı
      Keşke sadece Sparkplug B kullanıp onun üzerinde semantik için bir spesifikasyon uygulasalar
      Üstelik şu anda asenkron işlemlerle ilgili yaptıkları çalışma da aşırı tasarlanmış ve berbat. Bir süre toplantılara katıldım; MQTT spesifikasyonu 50 sayfadan kısa ve okuması kolay olmasına rağmen hiç okumamışlar, header'ın ne işe yaradığını da anlamamışlardı. Örneğin aslında payload'da olması gereken bir şeyi header'a koymaya çalışıyorlardı
      Microsoft tarafındaki bir kişi, MQTT ile rakiplerin ne yaptığına önce bakalım önerisine bile alındı. Çünkü kopyalamaktansa yeniden yapmak istiyordu
      Benim önerimle şirketimiz OPC UA'yı yalnızca en uç edge'de ele alacak ve teknolojimizden mümkün olduğunca izole edecek
    • Benim de MQTT'yi ilk gördüğüm yer kimyasal üretim tarafıydı; havacılık ve demiryolu kontrol sistemlerinde de çok gördüm
      Ancak son zamanlarda Kafka ve RabbitMQ'nun MQTT'nin pazar alanına daha fazla girdiğini de görüyorum
    • Eskiden Modbus kullanılacak yerlerde şimdi MQTT mi kullanılıyor merak ediyorum

  • Yaklaşık 15 yıl önce, tweet atan IoT cihazlarının yaygın olmadığı dönemde Andy Stanford Clark'ın evi haber olmuştu
    https://www.bbc.co.uk/blogs/technology/2009/06/things_that_t...
    Temel protokol, uydu bağlantısında 1 bayt göndermenin 1 dolar tuttuğu zamanlarda tasarlandığı için inanılmaz derecede verimli ve uygulaması da basit

  • Bir zamanlar bir müşterinin güvenlik duvarında kullanılabilen tek port MQTT 1883 idi
    Sensör verilerini o şekilde aldıkları içindi; ne kadar istesek de başka port açmadılar, biz de MQTT üzerinde gerçek zamanlı bir TCP wrapper yapıp etrafından dolaştık
    Yerel, çok iş parçacıklı bir TCP daemon'ı belirli bir porttan çıkan istekleri dinliyor, bunları MQTT ile sarıp benzersiz bir topic'e publish ediyordu; sunucu daemon'ı da o topic'i algılayıp paketi açıyor ve sunucu process'ine iletiyordu
    İstemci makine açısından bakıldığında sunucumuza gerçek zamanlı bir TCP bağlantısı kuruyormuş gibi görünüyordu, ama arada görünmez, tuhaf bir MQTT wrapper vardı
    Çalışmaya başladıktan sonra zarifti ama debug etmek gerçekten işkenceydi; birkaç çıkmaz sokaktan geçip her şeyi doğru oturtmamız aylar sürdü

    • Bu şekilde güvenlik duvarı kurallarını atlatmanın kovulmaya yol açabileceği yerlerde de çalıştım
      Artık hiçbir şey yapamayıp elim kolum bağlı beklemek zorunda kalmaya “sürecin işlemesine izin vermek” diyoruz
    • Fiilen MQTT-Sockets protokolünü uygulamışsınız; bununla karşı taraftaki WebSockets sunucusuna da bağlanabilirdiniz

  • İlginç bir bilgi: en ünlü C++ kütüphanesi Boost da aynı dönemde async-mqtt5 uygulamasını (https://github.com/mireo/async-mqtt5) Boost.MQTT olarak dahil edip etmeyeceğini inceleme sürecinde: https://lists.boost.org/Archives/boost/2024/10/index.php

    • İnsanların bugünlerde yeni projelerde hâlâ Boost'u seçip seçmediğini merak ediyorum
      Anekdot olarak, kullanımların çoğu 2000'ler ve C++0x/C++11'i herkes zorunlu kılmadan hemen önceki 2010'ların çok başlarında başlamıştı; bugünlerde ancak nadiren görüyorum
      boost.org zaman yolculuğu gibi. 2008 civarında hatırladığım haliyle aynı; acil durdurma düğmesine montajlanmış “Get Boost” bile duruyor

  • MQTT gerçekten iyi, küçük bir protokol; hobi projelerinde kullanılacak kadar “yeterince küçük” olmasının yanı sıra Facebook Messenger gibi şeylerde kullanılacak kadar da ölçeklenebiliyor
    [1]: https://engineering.fb.com/2011/08/12/android/building-faceb...

  • MQTT’nin hafif ve verimli olduğuna dair pazarlamayı pek ikna edici bulmuyorum
    Sonuçta sadece TCP/IP kullanıyor; o dönemin ölçütlerine göre görece özel sayılabilirdi ama bu iddiayı destekleyen, sürekli övünmeler dışında gerçek bir kanıt görmedim
    Standart olduğu için destekleyen hazır cihazlara bağlanabilmek iyi. Yine de yayın/abonelik ya da mesaj kuyrukları için daha iyi seçenekler olduğunu düşünüyorum; özellikle tüketici tarafında hata devri gerekiyorsa daha da öyle

    • Daha iyi seçeneklerin neler olduğunu merak ediyorum
      MQTT’nin iyi yanı ve gördüğüm neredeyse tüm diğer yayın/abonelik uygulamalarının yanlış yaptığı nokta, MQTT’nin temel veri yapısının kuyruklar ve topic’ler değil, abone istemciler olması
      Bu sayede istediğiniz kadar büyük bir adres alanını topic ağacına eşleyebilirsiniz. Topic ağacında trilyonlarca uç nokta olabilir; isterseniz gömülü bir sunucuda bile her IPv6 adresi için bir uç nokta koyabilirsiniz
      Topic ağacı zengin olduğu için abonelikleri gerektiği kadar seçici hâle getirebilirsiniz ve sunucu az kaynak kullanımıyla bile hızlı çalışabilir
    • Gerçekten, yayın/abonelik ve mesaj kuyrukları için daha iyi alternatiflerin neler olduğunu merak ediyorum

  • Birkaç yıldır IoT derslerinde MQTT kullanıyorum ve çok çok yönlü bir araç olduğu kanıtlandı
    WebSocket üzerinden de desteklenmesi kullanışlı

  • Yakın zamanda bir gömülü sistem projesinde MQTT’yi süreçler arası mesajlaşma sistemi olarak kullanmak oldukça eğlenceliydi
    Broker ve istemciler aynı makinede çalışıyordu
    Bir şeyi sniff etmek ya da hata ayıklamak gerektiğinde cihazı ağa bağlayıp MQTT Explorer ile mesajları kaydetmek veya enjekte etmek kolaydı
    LAN dışına port açarak uzaktan çalışan bir iş arkadaşının sistemle ilgilenmesini de sağlayabiliyorduk

    • Bu şekilde çok kullanıldığını görmedim ama iyi özellikleri var gibi görünüyor
      Sistem bileşeni olarak kullanırken en çok endişelendiğim şey dayanıklılık garantileri; broker uygulamasının veri kaybetmeyeceğine dair güvenim pek yüksek değil
    • Biz bu amaçla ZeroMQ kullanıyoruz. Broker gerekmiyor
    • Burada ZeroMQ bir alternatif olabilir mi?