Node.js डेवलपर टूल। वेब सॉकेट पर दूरस्थ प्रक्रिया कॉल

उदाहरण के लिए, डरावनी कहानियां अक्सर वेबसोकेट तकनीक के बारे में बताती हैं, कि यह वेब ब्राउज़र द्वारा समर्थित नहीं है, या प्रदाता / प्रशंसक वेबसोकेट ट्रैफ़िक को दबा देते हैं - इसलिए इसका उपयोग अनुप्रयोगों में नहीं किया जा सकता है। दूसरी ओर, डेवलपर्स हमेशा किसी भी अन्य तकनीक की तरह वेबस्कैट तकनीक के नुकसान को दूर नहीं करते हैं। कथित सीमाओं के अनुसार, मैं तुरंत कहूंगा कि 96.8% वेब ब्राउज़र आज वेबसोकेट तकनीक का समर्थन करते हैं। आप कह सकते हैं कि 3.2% शेष ओवरबोर्ड बहुत कुछ है, ये लाखों उपयोगकर्ता हैं। मैं आपसे पूरी तरह सहमत हूं। केवल सब कुछ तुलना में जाना जाता है। वही XmlHttpRequest, जिसे हर कोई कई वर्षों से अजाक्स में उपयोग कर रहा है, 97.17% वेब ब्राउज़र (बहुत अधिक, सही नहीं?) का समर्थन करता है, और सामान्य रूप से, वेब ब्राउज़र का 93.08% है। वेबसैट के विपरीत, इस तरह के प्रतिशत (और पहले यह और भी कम था) ने अजाक्स तकनीक का उपयोग करते समय किसी को भी लंबे समय तक नहीं रोका है। इसलिए वर्तमान में लंबे मतदान पर कमबैक का उपयोग करना कोई मायने नहीं रखता है। यदि केवल इसलिए कि वेब ब्राउज़र जो वेबसोकेट का समर्थन नहीं करते हैं, वही वेब ब्राउज़र हैं जो XmlHttpRequest का समर्थन नहीं करते हैं, और वास्तव में कोई भी गिरावट नहीं होगी।

दूसरी डरावनी कहानी, प्रदाताओं या कॉरपोरेट नेटवर्क के व्यवस्थापक से वेबसैट पर प्रतिबंध लगाना भी अनुचित है, क्योंकि अब हर कोई https प्रोटोकॉल का उपयोग करता है, और यह समझना असंभव है कि वेबसैट कनेक्शन खुला है (बिना ब्रेक के https)।

वास्तविक सीमाओं और उन्हें दूर करने के तरीकों के लिए, मैं इस पोस्ट में बताऊंगा, एप्लिकेशन के वेब व्यवस्थापक क्षेत्र को विकसित करने के उदाहरण पर।

तो, वेब ब्राउज़र में WebSocket ऑब्जेक्ट स्पष्ट रूप से, तरीकों का एक बहुत ही संक्षिप्त सेट है: send () और close (), साथ ही AddEventListener (), removeEventListener () और dispetEvent () EventTarget ऑब्जेक्ट से विरासत में मिली विधियों। इसलिए, डेवलपर को कई समस्याओं को हल करने के लिए पुस्तकालयों (आमतौर पर) या स्वतंत्र (लगभग असंभव) का उपयोग करना चाहिए।

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

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

वेबसैट के साथ काम करने के लिए अधिकांश पुस्तकालय प्रोग्रामर के लिए पारदर्शी होते हैं जो सर्वर से जुड़ते हैं। अपने कार्यान्वयन को विकसित करने की तुलना में ऐसी लाइब्रेरी का उपयोग करना हमेशा अधिक विश्वसनीय होता है।

अगला, आपको अतुल्यकालिक संदेश भेजने और प्राप्त करने के लिए बुनियादी ढांचे को लागू करने की आवश्यकता है। ऐसा करने के लिए, अतिरिक्त बंधन के बिना "नग्न" ऑनस्मेज ईवेंट हैंडलर का उपयोग करें, धन्यवाद कार्य। इस तरह का एक बुनियादी ढांचा हो सकता है, उदाहरण के लिए, दूरस्थ प्रक्रिया कॉल (RPC)। आईडी आईडी को json-rpc विनिर्देश में पेश किया गया था, विशेष रूप से वेबसोकेट परिवहन के साथ काम करने के लिए, जो आपको क्लाइंट द्वारा दूरस्थ प्रक्रिया कॉल को वेब सर्वर से प्रतिक्रिया संदेश में मैप करने की अनुमति देता है। मैं इस प्रोटोकॉल को अन्य सभी संभावनाओं के लिए पसंद करूंगा, लेकिन अभी तक मुझे नोड पर सर्वर के हिस्से के लिए इस प्रोटोकॉल का सफल कार्यान्वयन नहीं मिला है।

और अंत में, आपको स्केलिंग को लागू करने की आवश्यकता है। याद रखें कि क्लाइंट और सर्वर के बीच का संबंध समय-समय पर होता है। यदि एक सर्वर की शक्ति हमारे लिए पर्याप्त नहीं है, तो हम कई और सर्वर बढ़ा सकते हैं। इस मामले में, कनेक्शन काट दिए जाने के बाद, उसी सर्वर से कनेक्शन की गारंटी नहीं है। आमतौर पर, एक रेडिस सर्वर या रेडिस सर्वर के एक क्लस्टर का उपयोग कई वेबसोकेट सर्वरों के समन्वय के लिए किया जाता है।

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

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

इसलिए, मैं कई लोकप्रिय पुस्तकालयों पर विचार करने का प्रस्ताव करता हूं जो वेबसोकेट के साथ काम को लागू करते हैं।

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

मैं सबसे लोकप्रिय पुस्तकालय के साथ शुरू करूंगा - socket.io। अब आप राय सुन सकते हैं, सबसे अधिक संभावना है कि यह पुस्तकालय संसाधनों के मामले में धीमा और महंगा है। सबसे अधिक संभावना है, और यह देशी वेबस्कैट की तुलना में धीमी गति से काम करता है। हालांकि, आज यह अपने साधनों से सबसे विकसित पुस्तकालय है। और फिर से, जब वेबसोकेट के साथ काम करते हैं, तो मुख्य सीमित कारक गति नहीं है, लेकिन एक साथ अद्वितीय ग्राहकों के साथ एक साथ खुले कनेक्शन हैं। और यह सवाल ग्राहकों के साथ विशेष सर्वर से संबंध बनाने से पहले ही हल हो जाता है।

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

सॉकेट.आईओ की एक दिलचस्प विशेषता ईवेंट प्रोसेसिंग की पुष्टि है, जिसमें सर्वर से क्लाइंट को एक मनमाना ऑब्जेक्ट वापस किया जा सकता है, जो दूरस्थ प्रक्रिया कॉल की अनुमति देता है (हालांकि यह json-rpc मानक का पालन नहीं करता है)।

इसके अलावा, प्रारंभिक, मैंने दो और दिलचस्प पुस्तकालयों की जांच की, जिनके बारे में मैं नीचे संक्षेप में चर्चा करूंगा।

फेय लाइब्रेरी faye.jcoglan.com । यह Bayeux प्रोटोकॉल को लागू करता है, जिसे CometD प्रोजेक्ट में विकसित किया गया था और संदेश चैनलों के लिए सदस्यता / संदेश का वितरण लागू करता है। यह परियोजना सर्वर या रेडिस सर्वर के क्लस्टर का उपयोग करके स्केलिंग का भी समर्थन करती है। RPC को लागू करने का एक तरीका खोजने का प्रयास असफल रहा क्योंकि यह बायोकैम प्रोटोकॉल योजना में फिट नहीं था।

सॉकेटक्लस्टर socketcluster.io प्रोजेक्ट में, वेबसोकेट सर्वर को स्केल करने पर जोर दिया गया है। एक ही समय में, वेबसोकेट सर्वर क्लस्टर को रेडिस सर्वर के आधार पर नहीं बनाया गया है, जैसा कि पहले दो उल्लिखित पुस्तकालयों में है, लेकिन नोड के आधार पर। इस संबंध में, जब क्लस्टर की तैनाती करते हैं, तो दलालों और श्रमिकों के बजाय जटिल बुनियादी ढांचे को लॉन्च करना आवश्यक था।

अब socket.io पर RPC के कार्यान्वयन के लिए आगे बढ़ते हैं। जैसा कि मैंने ऊपर कहा, इस पुस्तकालय ने पहले ही ग्राहक और सर्वर के बीच वस्तुओं के आदान-प्रदान की क्षमता को लागू कर दिया है:

import io from 'socket.io-client'; const socket = io({ path: '/ws', transports: ['websocket'] }); const remoteCall = data => new Promise((resolve, reject) => { socket.emit('remote-call', data, (response) => { if (response.error) { reject(response); } else { resolve(response); } }); }); 

 const server = require('http').createServer(); const io = require('socket.io')(server, { path: '/ws' }); io.on('connection', (socket) => { socket.on('remote-call', async (data, callback) => { handleRemoteCall(socket, data, callback); }); }); server.listen(5000, () => { console.log('dashboard backend listening on *:5000'); }); const handleRemoteCall = (socket, data, callback) => { const response =... callback(response) } 

यह सामान्य योजना है। अब हम एक विशिष्ट अनुप्रयोग के संबंध में प्रत्येक भाग पर विचार करेंगे। व्यवस्थापक पैनल बनाने के लिए, मैंने प्रतिक्रिया-व्यवस्थापक लाइब्रेरी github.com/marmelab/react-admin का उपयोग किया । इस लाइब्रेरी में सर्वर के साथ डेटा विनिमय एक डेटा प्रदाता का उपयोग करके कार्यान्वित किया जाता है, जिसमें एक बहुत सुविधाजनक योजना है, लगभग एक तरह का मानक। उदाहरण के लिए, सूची प्राप्त करने के लिए, विधि को कहा जाता है:

 dataProvider( 'GET_LIST', ' ', { pagination: { page: {int}, perPage: {int} }, sort: { field: {string}, order: {string} }, filter: { Object } } 

अतुल्यकालिक प्रतिक्रिया में यह विधि एक वस्तु लौटाती है:

 { data: [  ], total:      } 

वर्तमान में विभिन्न सर्वरों और चौखटों के लिए प्रतिक्रिया-व्यवस्थापक डेटा प्रदाता कार्यान्वयनों की एक प्रभावशाली संख्या है (उदाहरण के लिए फायरबेस, स्प्रिंग बूट, ग्राफकल, आदि)। RPC के मामले में, कार्यान्वयन सबसे संक्षिप्त हो गया, क्योंकि ऑब्जेक्ट को उसके मूल रूप में एमिर फ़ंक्शन कॉल में स्थानांतरित किया गया है:

 import io from 'socket.io-client'; const socket = io({ path: '/ws', transports: ['websocket'] }); export default (action, collection, payload = {}) => new Promise((resolve, reject) => { socket.emit('remote-call', {action, collection, payload}, (response) => { if (response.error) { reject(response); } else { resolve(response); } }); }); 

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

 const Router = require('./router'); const router = Router(); router.use('GET_LIST', (socket, payload, callback) => { const limit = Number(payload.pagination.perPage); const offset = (Number(payload.pagination.page) - 1) * limit return callback({data: users.slice(offset, offset + limit ), total: users.length}); }); router.use('GET_ONE', (socket, payload, callback) => { return callback({ data: users[payload.id]}); }); router.use('UPDATE', (socket, payload, callback) => { users[payload.id] = payload.data return callback({ data: users[payload.id] }); }); module.exports = router; const users = []; for (let i = 0; i < 10000; i++) { users.push({ id: i, name: `name of ${i}`}); } 

राउटर के कार्यान्वयन का विवरण परियोजना भंडार में पाया जा सकता है।

सभी जो व्यवस्थापक घटक के लिए एक प्रदाता को असाइन करना है:

 import React from 'react'; import { Admin, Resource, EditGuesser } from 'react-admin'; import UserList from './UserList'; import dataProvider from './wsProvider'; const App = () => <Admin dataProvider={dataProvider}> <Resource name="users" list={UserList} edit={EditGuesser} /> </Admin>; export default App; 

उपयोगी लिंक

1. www.infoq.com/articles/Web-Sockets-Proxy-Servers

apapacy@gmail.com
14 जुलाई, 2019