Node.js डेवलपर टूल। वेब सॉकेट्स के साथ काम करने के लिए Mqtt प्रोटोकॉल

वेब सॉकेट तकनीक किसी सर्वर से क्लाइंट को वेब एप्लिकेशन या मोबाइल एप्लिकेशन में संदेश भेजने की अनुमति देती है, जो REST-API का उपयोग करके नहीं किया जा सकता है। वेब सॉकेट्स के साथ काम करने के लिए, वे अक्सर सॉकेट का उपयोग करते हैं। पुस्तकालय, या डेवलपर्स देशी ब्राउज़र वेब सॉकेट ऑब्जेक्ट्स के साथ काम करते हैं। इस पोस्ट में, मैं यह दिखाने की कोशिश करूंगा कि दोनों तरीके सभी समस्याओं को हल नहीं करते हैं, और विशेष सर्वर का उपयोग करना बेहतर है, उदाहरण के लिए, वेब सॉकेट्स के साथ काम करने के लिए mqtt सर्वर (इसे पहले mqtt दलाल कहा जाता था)।

निष्पक्षता में, और अनावश्यक विवादों से बचने के लिए, मैं ध्यान देता हूं कि mqtt सर्वर के अलावा, कई अन्य सर्वर का उपयोग किया जा सकता है, उदाहरण के लिए खरगोश।

वेब सॉकेट्स का उपयोग करते हुए एप्लिकेशन विकसित करना तब तक बहुत सरल लगता है जब तक कि हम एक वास्तविकता के पार नहीं आते हैं जिसमें अक्सर कनेक्शन टूट जाता है। पहला काम जिसे हल करना है, वह कनेक्शन ब्रेक को ट्रैक करना और उन्हें पुनर्स्थापित करना है। स्थिति इस तथ्य से जटिल है कि वियोग और पुन: संयोजन के दौरान, ग्राहक नए संदेश भेजना जारी रखता है, साथ ही ग्राहक को नए संदेश भेजे जा सकते हैं जो खो जाने की अधिक संभावना है।

संदेशों की प्राप्ति की निगरानी के लिए, और उनके दोहराया वितरण को लागू करने के लिए आवेदन स्तर पर यह आवश्यक है। मैं विशेष रूप से "एप्लिकेशन स्तर पर" वाक्यांश पर ध्यान आकर्षित करना चाहूंगा (लेकिन मैं इसे प्रोटोकॉल स्तर पर होना चाहूंगा)।

जैसे ही हमने संदेश वितरण पर नज़र रखने के लिए तर्क जोड़ा, सभी संदेश आने शुरू हो गए, लेकिन यह तुरंत स्पष्ट हो गया कि नकली संदेश थे, चूंकि संदेश प्राप्त हो सकता था, और इस तथ्य की पुष्टि एक कटे हुए कनेक्शन के कारण खो गई थी। और आपको डुप्लिकेट संदेशों को बाहर करने के लिए प्रोग्राम कोड की मात्रा को दोगुना करने की आवश्यकता है।

प्रोग्राम कोड की जटिलता के साथ, इसकी दक्षता भी कम हो जाती है, जिसके लिए वे अक्सर सॉकेट.आईओ लाइब्रेरी की आलोचना करते हैं। यह, निश्चित रूप से, मूल वेब सॉकेट्स के साथ काम करने की तुलना में कम प्रभावी है, विशेष रूप से, सामंजस्य तर्क और संदेश वितरण पुष्टिकरण की उपस्थिति के कारण (मैं तुरंत ध्यान देता हूं कि पुन: वितरण तर्क सॉकेट में लागू नहीं किया गया है।)।

इस तर्क को प्रोटोकॉल स्तर तक लाने के लिए एक अधिक विश्वसनीय और कुशल तरीका होगा। और इस तरह के एक प्रोटोकॉल मौजूद है - यह mqtt है। Mqtt प्रोटोकॉल का पहला संस्करण एंडी स्टैनफोर्ड-क्लार्क (IBM) और अर्लेन नेपर (Arcom) द्वारा 1999 में विकसित किया गया था। MQTT 3.1.1 विनिर्देश 2014 में OASIS संघ द्वारा मानकीकृत किया गया था।

Mqtt प्रोटोकॉल में "सेवा की गुणवत्ता" (qos) पैरामीटर है जो मान ले सकता है:
0 - यदि संभव हो तो संदेश दिया जाता है;
1 - संदेश की गारंटी दी जाती है, लेकिन डुप्लिकेट हो सकते हैं;
2 - संदेश की गारंटी और गारंटी एक बार दी जाती है।

यही है, mqtt प्रोटोकॉल गारंटीकृत संदेश वितरण के साथ समस्या को हल करता है, और इस मुद्दे को एजेंडा से हटा दिया जाता है। लेकिन यह सवाल ही नहीं।

प्रदर्शन और स्केलिंग।

वेब सॉकेट्स के साथ काम करते समय, सभी कनेक्टेड क्लाइंट सर्वर से खुले कनेक्शन छोड़ देते हैं, भले ही कोई वास्तविक संदेश न हो। यह लोड REST-API में लोड से स्वाभाविक रूप से भिन्न है, जो अनुरोधों के प्रवाह द्वारा निर्धारित किया जाता है। वेब सॉकेट पर खुले कनेक्शन का बोझ परीक्षण चरण के दौरान अनुकरण करना मुश्किल है। इसलिए, ग्राहकों के साथ बड़ी संख्या में खुले कनेक्शन को बनाए रखने पर लोड को ध्यान में रखे बिना, भेजे और प्राप्त किए गए संदेशों की संख्या के द्वारा आवेदन के पर्याप्त प्रदर्शन के बारे में अक्सर एक गलत धारणा बनाई जाती है।

यदि हम वेब सॉकेट के साथ सभी काम एक विशेष mqtt सर्वर में स्थानांतरित करते हैं, तो हमारा नोडज एप्लिकेशन वेब सॉकेट (या टीसीपी पर केवल एक कनेक्शन खोलता है, क्योंकि mqtt दोनों प्रोटोकॉल का समर्थन करता है) एक mqtt सर्वर के साथ, और हम कर सकते हैं नोड के कई उदाहरणों को mqtt सर्वर से जोड़कर हमारे एप्लिकेशन को स्केल करें।

यदि एक mqtt सर्वर के संसाधन समाप्त हो जाते हैं, तो आप नोडज पर एप्लिकेशन को प्रभावित किए बिना mqtt सर्वर के क्लस्टर को व्यवस्थित कर सकते हैं।

अब एक उदाहरण पर चलते हैं।

Mqtt सर्वर या ब्रोकर, जैसा कि पिछले विनिर्देशों में कहा गया था, संदेश भेजने / संदेश भेजने के मॉडल के अनुसार काम करता है। प्रत्येक संदेश विषय पर भेजा जाता है। प्राप्तकर्ता संदेश थ्रेड की सदस्यता लेता है। प्रेषक और रिसीवर दोनों के दो पहचानकर्ता हैं: क्लाइंटआईड (डिवाइस पहचानकर्ता) और उपयोगकर्ता नाम (उपयोगकर्ता नाम)।

डिवाइस पहचानकर्ता महत्वपूर्ण है, क्योंकि यह सदस्यता से जुड़ा हुआ है और इसे संदेश भेजे जाएंगे। उपकरण पहचानकर्ता के विपरीत उपयोगकर्ता नाम, संदेश वितरण में निर्णायक भूमिका नहीं निभाता है, और इसका उपयोग विषयों में अंतर करने के लिए किया जाता है।

क्लाइंट पक्ष पर mqtt प्रोटोकॉल के साथ काम करने के लिए, पुस्तकालय github.com/eclipse/paho.mqtt.javascript का उपयोग किया जाता है। फ्री सहित कई सर्वर कार्यान्वयन हैं। इस उदाहरण में, हम emqx सर्वर का उपयोग करेंगे, जो docker- रचना के माध्यम से चलता है (देखें github.com/apapacy/tut-mqtt )।

परीक्षण के लिए, एक दस्तावेज बनाएं जिसमें हम क्लाइंटआईड, यूजरनेम और संदेश पाठ सेट करेंगे:

<script src="/paho-mqtt.js"></script> <script src="/messages.js"></script> <form name="sender" onsubmit="return false"> <input type="text" name="user"> <input type="text" name="client"> <input type="text" name="message"> <input type="button" onclick="connect()" value="connect"> <input type="button" onclick="send()" value="send"> </form> 

संदेश भेजना message.js फ़ाइल में कार्यान्वित किया जाता है:

 var client; var connectOptions = { timeout: 30, reconnect: true, cleanSession: false, mqttVersion: 4, keepAliveInterval: 10, onSuccess: onConnect, onFailure: onFailure } function connect() { try { client = new Paho.Client('localhost', 8083, '/mqtt', document.forms.sender.client.value); connectOptions.userName = document.forms.sender.user.value; client.connect(connectOptions); } catch (ex) { console.log(ex); } } function onConnect() { console.log('on connect'); client.onMessageArrived = function(message) { console.log("onMessageArrived: " + message.payloadString); } client.subscribe("test", { qos: 2 }); } function onFailure(err) { console.log('on failure', JSON.stringify(err)); } function send() { var message = new Paho.Message(document.forms.sender.message.value); message.destinationName = "test"; message.qos = 2; client.send(message); } 

ब्राउज़र में index.html फ़ाइल खोलने के लिए, clientId, userName, संदेश पाठ निर्दिष्ट करें, और कई संदेश भेजें (आप उन्हें कंसोल में पढ़ सकते हैं, जैसा कि ग्राहक परीक्षण विषय को संदेश भेजता है, और इस विषय के लिए सदस्यता लिया है)।

अब एक अन्य ब्राउज़र या अन्य ब्राउज़र टैब खोलें, और दूसरे के साथ जुड़ें (यह महत्वपूर्ण है) क्लाइंटआईड। पहले ब्राउज़र से कुछ और संदेश भेजें, और सुनिश्चित करें कि वे दोनों क्लाइंट के पास आते हैं, क्योंकि उनके पास अलग-अलग क्लाइंटआईड हैं और वे दोनों विषय परीक्षण के लिए सब्सक्राइब किए गए हैं।

अब दूसरा ब्राउज़र (या दूसरा ब्राउज़र टैब) बंद करें, और कुछ और संदेश भेजें। उसके बाद, दूसरा ब्राउज़र फिर से खोलें, और उसी क्लाइंटआईड के साथ जुड़ें। कंसोल लॉग में सुनिश्चित करें कि आपको वह सभी संदेश मिले हैं जो उस अवधि के दौरान भेजे गए थे जब दूसरा ब्राउज़र (दूसरा टैब) बंद हो गया था। ऐसा इसलिए हुआ क्योंकि:

• संदेश भेजते समय, गुणवत्ता स्तर qos = 2 सेट किया गया था;
• आप पहले qos = 2 सेट करके एक ही क्लाइंटआईड के साथ एक ही विषय में शामिल हो गए हैं;
• कनेक्शन विकल्प क्लीन सेशन पर सेट हैं: असत्य।

सैंपल कोड रिपॉजिटरी से डाउनलोड किया जा सकता है ।

apapacy@gmail.com
29 सितंबर, 2019