MQTT के 25 साल

 (andypiper.co.uk)
4 पॉइंट द्वारा GN⁺ 2024-10-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • MQTT की पहली specification अक्टूबर 1999 में सार्वजनिक होने के बाद 25 वर्षों में यह छोटे devices और अस्थिर networks के लिए बने lightweight protocol से बढ़कर उद्योग, घर और apps तक फैल गया है
  • सीमित power और रुक-रुक कर मिलने वाले connection को ध्यान में रखकर बना इसका सरल publish/subscribe ढांचा नेटवर्क और edge device environments बदल जाने के बाद भी इसकी ताकत बना हुआ है
  • IBM के आसपास इस्तेमाल होने वाला MQTT, 2009~2011 के दौरान समुदाय में गंभीर रूप से फैलना शुरू हुआ और Mosquitto व Eclipse Paho के जरिए IBM के बाहर एक open protocol ecosystem तक विस्तृत हुआ
  • आज यह Node-RED आधारित Raspberry Pi message processing, Dyson air purifier और apps, 3D printer control, home notifications, manufacturing floor आदि जैसे उन स्थानों में भी मौजूद है जहाँ उपयोगकर्ता अक्सर इसे नोटिस नहीं करते
  • 25वीं वर्षगांठ पर समुदाय ने X के पुराने project account की जगह Mastodon के @mqtt@fosstodon.org पर जाना शुरू किया और ActivityPub आधारित Fediverse में भी पहला संदेश पोस्ट किया

सीमित वातावरण से शुरू हुई lightweight messaging

  • अक्टूबर 2024, MQTT की पहली specification तक पहुँचे दस्तावेज़ के सार्वजनिक होने की 25वीं वर्षगांठ है
  • MQTT एक network protocol है जिसे 1990 के दशक के उत्तरार्ध के छोटे और सीमित devices तथा हल्के या अस्थिर networks को ध्यान में रखकर डिज़ाइन किया गया था
  • इसका फोकस ऐसे sensor data को बड़े systems तक पहुँचाने पर था, जहाँ connection रुक-रुक कर मिलता हो और power भी सीमित हो, जैसे दूरस्थ environment monitoring devices
    • ऐसे devices को power, bandwidth और network availability का बहुत किफ़ायती उपयोग करना पड़ता है
    • MQTT, data को छोटे लेकिन उपयोगी format में publish करने और उसे collect व receive करने के तरीके के लिए बहुत उपयुक्त है
  • नेटवर्क अधिक तेज़ और स्थिर हो जाने तथा edge, home automation और portable devices बढ़ जाने के बाद भी, protocol की simplicity MQTT की मुख्य ताकत बनी हुई है

IBM के आसपास से open ecosystem तक विस्तार

  • 2001 में IBM में शामिल होने के बाद IBM MQ, business integration, message queuing, application connectivity और middleware से जुड़े customer projects पर काम किया गया
  • IBM Hursley Lab, MQ की नींव और MQTT के सह-निर्माता Andy Stanford-Clark की गतिविधियों का केंद्र था, और MQTT के प्रयोग भी उसी के आसपास शुरू हुए
  • उस समय MQTT बाहर की दुनिया के लिए protocol के रूप में सार्वजनिक था, लेकिन IBM के बाहर न तो यह बहुत जाना जाता था और न ही व्यापक रूप से implement किया गया था
  • 2009~2011 के आसपास MQTT को IBM के छोटे implementation दायरे से बाहर पहचान दिलाने की कोशिशों में प्रगति हुई
    • उस समय broker विकल्पों में enterprise और महँगा IBM WebSphere Message Broker, closed-source microbroker, और closed-source लेकिन मुफ़्त Really Small Message Broker शामिल थे
    • Roger Light द्वारा बनाया गया open-source Mosquitto आज भी सबसे व्यापक रूप से इस्तेमाल होने वाले मुफ़्त implementations में से एक है
    • Roger Light ने 2009 के पहले OggCamp में Andy Stanford-Clark की connected smart home प्रस्तुति सुनने के बाद Mosquitto बनाया, और यह specification के बनने के 10 साल बाद हुआ

Eclipse Paho और आधिकारिक standardization

  • 2011 में IBM की MQTT implementation को Eclipse community को दान किए जाने के साथ Eclipse Paho project की शुरुआत हुई
  • 2012 में IBM छोड़ने के बाद भी Paho project से जुड़ाव बना रहा, और Cloud Foundry में काम करते समय भी इसमें भूमिका रही
  • 2014 में Twitter में शामिल होने के बाद औपचारिक भागीदारी से दूरी बन गई
  • उसी अवधि में MQTT ने OASIS और ISO/IEC में आधिकारिक standardization process पूरा किया

आज की अदृश्य दुनिया में MQTT

  • MQTT, IBM की सीमाओं से बाहर निकलकर open protocol की एक success story बन चुका है, और 25 साल बाद यह कई ऐसे products और जगहों में मौजूद है जिन्हें उपयोगकर्ता सीधे पहचान भी नहीं पाते
  • इसके प्रमुख उपयोग इस प्रकार हैं
    • hobby developers और makers के projects
    • Dyson air purifier और उससे जुड़े apps
    • 3D printer control systems
    • home notification systems
    • industry और manufacturing sites
  • व्यक्तिगत workspace में भी MQTT कई तरीकों से इस्तेमाल हो रहा है
    • Bambu Lab X1C 3D printer अपनी internal communication के लिए MQTT का उपयोग करता है
    • दीवार पर लगे connected devices MQTT notifications पर प्रतिक्रिया देकर data दिखाते हैं या lights on करते हैं
    • Raspberry Pi पर चल रहा Node-RED MQTT messages को process करता है
  • संभावना काफ़ी अधिक है कि आपके फ़ोन के apps में से कम-से-कम एक कहीं न कहीं अपने stack में MQTT का उपयोग करता हो

25वीं वर्षगांठ और community migration

  • MQTT community account ने पुराने X project account की जगह Mastodon पर जाना शुरू किया है
  • नया account @mqtt@fosstodon.org पर follow किया जा सकता है
  • 25वीं वर्षगांठ के मौके पर MQTT ने ActivityPub के जरिए Fediverse पर अपना पहला संदेश पोस्ट किया और open social web में शामिल हुआ
  • Andy Stanford-Clark ने HiveMQ के साथ fireside chat किया, और HiveMQ के podcast The Unstructured Message को MQTT पर और सामग्री देखने की जगह के रूप में भी बताया गया

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-10-23
Hacker News की राय

  • मेरा पहला प्रोजेक्ट जो अब भी चल रहा है और रोज़ इस्तेमाल होता है, एक बड़े ski resort की snowmaking और fire-fighting पाइपिंग/पंप/वाल्व water system की SVG map को status display website में बदलना था
    हर pump, valve और pipe section के लिए एक MQTT topic बनाया, उसमें पानी के flow की दिशा, pump/valve on-off, pressure जैसी status जोड़ी, और mqtt.js व jQuery से SVG के रंग और fill अपडेट किए
    static hosting पर container में चलाया गया MQTT broker लगभग 10 साल से बिना छुए चल रहा है, और mqtt.js WebSocket के ऊपर काम करता है, इसलिए status बदलते ही वह सबके लिए अपने-आप reflect हो जाता है

    • यह हैरानी की बात है कि Docker अब 11 साल पुरानी technology हो चुकी है

  • हाल के एक project में MQTT इस्तेमाल किया, लेकिन वह खास पसंद नहीं आया
    protocol में बहुत सारे options हैं, और हर option क्या करता है, क्यों महत्वपूर्ण है, और किस combination में इस्तेमाल करने पर वह intended तरीके से काम करेगा—यह तुरंत समझना मुश्किल था; documentation भी यह ठीक से नहीं समझाती
    इसका कुछ हिस्सा शायद इस्तेमाल किए गए Eclipse Mosquitto Python client की वजह से रहा हो, लेकिन एक slow system पर race condition बन गई, जिससे topic subscriptions चुपचाप ignore हो गए और callbacks बिगड़ गए; यह पता लगाने में कई दिन लग गए
    documentation को 100% follow करने के बावजूद ऐसा हुआ, और किसी बहुत पुराने न लगने वाले protocol के हिसाब से यह मेरे सबसे messy experiences में से एक था

    • यहाँ शायद client ही ठीक नहीं था
      Eclipse clients, जैसे Paho, को Python और C++ में इस्तेमाल करने का मेरा अनुभव भी मिलता-जुलता था; वे जरूरत से ज्यादा complex और बहुत low-level जैसे लगे, और उनकी structure की वजह से कुछ bugs भी थे
      शायद इसलिए कि लगभग एक ही व्यक्ति इन्हें maintain कर रहा है, समय के साथ यह स्थिति बन गई है। C++ client में भी पिछले 6 महीनों में सिर्फ एक contributor था और पिछले 3 महीनों में किसी ने contribute नहीं किया
      एक स्पष्ट bug ठीक करने वाला simple PR, यहाँ तक कि एक शब्द बदलने जितना, review और merge होने में 2 साल ले गया। यह दोष देने के लिए नहीं है, बल्कि मतलब यह है कि libraries, bugs और काम बहुत ज्यादा हैं, और कुछ overworked लोग ही उन्हें संभाल रहे हैं
      दूसरे clients पर जाने के बाद Python, Rust, C#, C++ में अनुभव कहीं बेहतर हो गया, और अधिकतर में high-level व low-level APIs का अच्छा combination था, इसलिए अगर आप सिर्फ किसी topic पर message भेजना चाहते हैं तो acknowledgements या retries जैसी चीज़ों की चिंता नहीं करनी पड़ती
      वहीं अगर control चाहिए तो वह भी कर सकते हैं। चिंता होती है कि क्या paho वगैरह को मौजूदा हालत में जिंदा रखना उल्टा नुकसानदेह तो नहीं है। अगर उन्हें officially dead घोषित कर दिया गया होता, तो कम से कम समस्या मजबूरन सामने आती; अभी users ऐसा अनुभव करते हैं और MQTT छोड़ देते हैं या सोचते हैं कि गलती उनकी है
    • मैं paho Python MQTT library से MQTT इस्तेमाल करता रहा हूँ और उससे काफी चीज़ें बनाई भी हैं, लेकिन कुल मिलाकर अनुभव बेहद खराब था
      API design, कमजोर documentation, और Python conventions को न मानने जैसा तरीका—सब खटकता था
      शुरुआत में यह आसान लगता है, लेकिन protocol और implementation की breadth धीरे-धीरे अड़चन बनती जाती है। एक समय server से successfully connect हुआ या नहीं, यह check करने का भरोसेमंद तरीका था कि उसी topic को दो बार subscribe करके on_connect message में एक खास error code पकड़ा जाए। उस समय वह code documentation में success code बताया गया था
      मुझे पता है यह बेतुका लगता है, लेकिन अगर कोई बेहतर तरीका था भी तो वह आसानी से मिल नहीं रहा था। फिर भी शिकायत करना आसान है, और मैं इस library बनाने वाले कई लोगों का आभारी हूँ। उनके बिना मैं जो बना पाया, वह नहीं बना पाता, और ऐसे विशाल projects उठाने वालों का सम्मान करता हूँ
    • Python, C, C++ में Paho API इस्तेमाल करके देखा, लेकिन आखिर में सब छोड़ दिए
      जहाँ संभव हो, मैंने protocol को mosquitto_sub और mosquitto_pub से handle करने और सिर्फ standard input/output पढ़ने-लिखने का रास्ता चुना
      यह सिर्फ bugs की वजह से नहीं था; broker connection management को पहले से लिखे और tested program पर छोड़ना ज्यादा आसान था
      हालांकि will message के लिए यह तरीका प्रभावी ढंग से इस्तेमाल नहीं कर पाया, और यह Linux जैसी चीज़ न चलाने वाले microcontrollers के लिए भी suitable नहीं है
    • MQTT का सीधा competitor तो नहीं, लेकिन https://pipe.pico.sh SSH के जरिए communicate करने वाला बेहतरीन publish/subscribe tool है
      यह असल में authenticated network *nix pipe system बनाता है, और events भेजने व पाने का सबसे सरल तरीका बनने का लक्ष्य रखता है
    • कहीं “सिर्फ TCP क्यों न इस्तेमाल करें” जैसा देखा था, और मेरे IoT project के लिए plain TCP काफी था
      मेरे use case में infinite queue महत्वपूर्ण थी, लेकिन MQTT वह नहीं देता था; और अगर MQTT को अपने message IDs track करके broker को भेजने के लिए मुझे फिर खुद message IDs manage करने पड़ें, तो उसे इस्तेमाल करने की खास वजह नहीं बचती
      अगर पहले से MQTT के लिए बने project के साथ integrate नहीं करना है, तो इसका सबसे अच्छा use case क्या है, यह मुझे ठीक से समझ नहीं आता

  • पिछले कुछ वर्षों में MQTT का इस्तेमाल फैक्टरी के अंदर मशीनों के बीच डेटा शेयर करने के लिए काफी बढ़ा है
    ऐतिहासिक रूप से यह Oil & Gas सेक्टर में दूरस्थ oil well साइट्स से डेटा लाने के लिए SCADA उपयोग में आता था
    10 साल से भी ज्यादा पहले Kepware (OPC server) में MQTT जोड़कर tag values को “cloud” में stream किया था, और presentation के बाद MQTT के creators में से एक Arlen Nipper आए और बोले “ठीक-ठाक किया”, जिससे काफी विनम्र महसूस हुआ
    अब HighByte नाम की नई कंपनी में edge पर factory data को model कर रहे हैं और उसे MQTT, SparkplugB (MQTT के ऊपर protocol), S3, Azure Blob आदि पर भेज रहे हैं
    सार यह है कि MQTT Industry 4.0 की बड़ी driving force है, और इतने लंबे समय बाद भी इसका इतना इस्तेमाल होना शानदार है

    • फिलहाल Kepware IoT plugin से प्रति सेकंड लगभग 8 लाख tags MQTT पर stream करके अंत में VictoriaMetrics DB में डाल रहे हैं
      यह थोड़ा कच्चा है और हमारी इच्छा से ज्यादा processing stages हैं। Kepware IoT plugin पर हर साल recurring license fee लगाता है, इसलिए अब उस solution से हटकर telegraf को Kepware से OPC-UA data सीधे पढ़ाने की दिशा में जा रहे हैं
      उत्सुकता है कि आपने Kepware में काम किया है या कर रहे हैं
    • मैं भी इसी industry में काम करता हूं, और OPC Foundation standards की technical कमजोरी, scope creep और NIH syndrome काफी हैरान करने वाले हैं
      काश वे बस Sparkplug B इस्तेमाल करें और उसके ऊपर semantics के लिए specification implement करें
      ऊपर से अभी जो asynchronous work कर रहे हैं वह भी बहुत over-engineered और खराब है। मैं कुछ समय meetings में शामिल रहा, और हालत यह थी कि MQTT specification 50 pages से कम और पढ़ने में आसान होने के बावजूद उन्होंने उसे पढ़ा तक नहीं था और header किस काम के लिए है यह भी नहीं समझते थे। मसलन, जो चीज असल में payload में जानी चाहिए थी उसे header में डालने की कोशिश कर रहे थे
      Microsoft की तरफ के एक व्यक्ति को यह सुझाव भी बुरा लगा कि पहले देख लें competitors MQTT के साथ क्या कर रहे हैं। वजह यह थी कि वे copy करने के बजाय नया बनाना चाहते थे
      मेरे सुझाव पर हमारी कंपनी OPC UA को केवल बिल्कुल edge पर handle करेगी, और उसे हमारी technology से जितना हो सके isolate रखेगी
    • मैंने भी MQTT पहली बार chemical production के क्षेत्र में देखा था, और aviation व railway control systems में भी काफी देखा है
      हालांकि आजकल Kafka और RabbitMQ को भी MQTT के market area में ज्यादा घुसते हुए देखता हूं
    • जिज्ञासा है कि क्या MQTT अब उन जगहों पर इस्तेमाल हो रहा है जहां पहले Modbus इस्तेमाल होता

  • करीब 15 साल पहले, जब tweet करने वाले IoT devices आम नहीं थे, Andy Stanford Clark का घर news में आया था
    https://www.bbc.co.uk/blogs/technology/2009/06/things_that_t...
    core protocol उस दौर में सोचा गया था जब satellite link पर 1 byte भेजने में 1 dollar लगता था, इसलिए यह अविश्वसनीय रूप से efficient है और implement करना भी सरल है

  • एक बार पहले एक client के firewall में इस्तेमाल किया जा सकने वाला एकमात्र port MQTT 1883 ही था
    वे sensor data इसी तरह ले रहे थे, और कितनी भी request करने पर भी कोई और port नहीं खोलते थे, इसलिए bypass के लिए MQTT के ऊपर real-time TCP wrapper बना दिया
    local multithreaded TCP daemon किसी खास port पर outgoing requests सुनता था, उन्हें MQTT में wrap करके unique topic पर publish करता था, और server daemon उस topic को detect करके unwrap करता था और server process को forward कर देता था
    client machine के नजरिए से ऐसा दिखता था मानो वह हमारे server से real-time TCP connection बना रही हो, लेकिन बीच में एक अदृश्य अजीब MQTT wrapper था
    चलने के बाद यह elegant था, लेकिन debugging सच में दर्दनाक थी, और कई dead ends से गुजरकर पूरी चीज सही बैठाने में महीनों लग गए

    • ऐसी जगहों पर भी काम किया है जहां इस तरह firewall rules को bypass करने पर नौकरी जा सकती थी
      अब ऐसी स्थिति को, जिसमें आप कुछ नहीं कर सकते और बस हाथ मलते रहते हैं, “process को काम करने देना” कहा जाता है
    • असल में आपने MQTT-Sockets protocol implement किया था, और उससे दूसरी तरफ WebSockets server से भी connect किया जा सकता था

  • मजेदार बात यह है कि सबसे मशहूर C++ libraries में से एक Boost इसी समय async-mqtt5 implementation (https://github.com/mireo/async-mqtt5) को Boost.MQTT के रूप में शामिल करने पर review कर रहा है: https://lists.boost.org/Archives/boost/2024/10/index.php

    • उत्सुकता है कि क्या आजकल नए projects में भी लोग अब भी Boost चुनते हैं
      अनुभव के तौर पर, adoption ज्यादातर 2000s और बहुत शुरुआती 2010s में था, यानी उस समय से पहले जब सबने C++0x/C++11 को enforce करना शुरू किया; आजकल यह बहुत कम ही दिखता है
      boost.org किसी time travel जैसा लगता है। 2008 के आसपास जैसा याद है वैसा ही है, और emergency stop button पर चिपका “Get Boost” भी जस का तस है

  • MQTT सचमुच एक अच्छा छोटा protocol है, और hobby projects में इस्तेमाल के लिए “काफी छोटा” होने के साथ-साथ Facebook Messenger जैसी चीजों तक scale भी हो जाता है
    [1]: https://engineering.fb.com/2011/08/12/android/building-faceb...

  • MQTT के हल्का और efficient होने जैसी promotion वाली बात मुझे ठीक से समझ नहीं आती
    आखिरकार यह सिर्फ़ TCP/IP ही इस्तेमाल करता है, और उस समय के हिसाब से शायद यह तुलनात्मक रूप से खास रहा हो, लेकिन ऐसे दावे को सपोर्ट करने वाला असली सबूत मैंने लगातार की जाने वाली तारीफ़ों के अलावा कभी नहीं देखा
    यह अच्छा है कि standard होने की वजह से इसे support करने वाले off-the-shelf devices से connect किया जा सकता है। फिर भी publish/subscribe या message queues के लिए मुझे लगता है कि बेहतर विकल्प हैं, खासकर अगर consumer side पर failover की ज़रूरत हो

    • जानना चाहूँगा कि बेहतर विकल्प कौन-से हैं
      MQTT की अच्छी बात—और लगभग हर दूसरे publish/subscribe implementation में जो मैंने गलत होते देखा है—यह है कि MQTT का core data structure queues और topics नहीं, बल्कि subscribing client है
      इसलिए आप जितना बड़ा चाहें उतना address space topic tree पर map कर सकते हैं। topic tree में खरबों endpoints हो सकते हैं, और अगर चाहें तो embedded server पर भी हर IPv6 address के लिए एक endpoint रखा जा सकता है
      topic tree rich होने से subscriptions को जितना चाहें उतना selective बनाया जा सकता है, और server छोटे resource usage के साथ भी तेज़ी से चल सकता है
    • सच में, publish/subscribe और message queues में बेहतर alternatives क्या हैं, जानना चाहूँगा

  • कई सालों से IoT classes में MQTT इस्तेमाल कर रहा हूँ, और यह बहुत versatile tool साबित हुआ है
    WebSocket पर भी support होना सुविधाजनक है

  • हाल के एक embedded systems project में MQTT को inter-process messaging system की तरह इस्तेमाल किया, और यह काफ़ी मज़ेदार रहा
    broker और clients उसी machine पर चल रहे थे
    अगर कुछ sniff या debug करना होता, तो device को network से जोड़कर MQTT Explorer से messages record या inject करना आसान था
    LAN के बाहर port खोलकर remote work कर रहे colleague को भी system handle करने दिया जा सकता था

    • इस तरह इसका ज़्यादा इस्तेमाल होते नहीं देखा, लेकिन इसमें desirable characteristics दिखती हैं
      system component के तौर पर इस्तेमाल करते समय मेरी सबसे बड़ी चिंता durability guarantees है, और broker implementation data नहीं खोएगा—इस पर मेरा भरोसा बहुत ज़्यादा नहीं है
    • हम इस use case के लिए ZeroMQ इस्तेमाल करते हैं। broker की ज़रूरत नहीं होती
    • यहाँ ZeroMQ alternative हो सकता है, है न?