कुशल सिग्नलआर कनेक्शन प्रबंधन

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

परिचय

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

चुनौतियों

प्रोग्रामिंग में शायद सबसे दिलचस्प बात गैर-मानक समस्याओं को हल करने की क्षमता है। और आज हम इन कार्यों में से एक को नामित करेंगे और इसके समाधान पर विचार करेंगे।

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



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

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

हमें कनेक्ट करने की आवश्यकता क्यों है

जैसा कि पहले उल्लेख किया गया है, सिग्नलआर एक प्रकाशक-ग्राहक मॉडल प्रदान करता है। यहां, संदेश रूटिंग की इकाई एक कनेक्शनआईडी नहीं बल्कि एक समूह है। एक समूह कनेक्शन का एक संग्रह है। एक समूह को एक संदेश भेजकर, हम सभी कनेक्शनआईडी को एक संदेश भेजते हैं जो इस समूह में हैं। समूहों का निर्माण करना सुविधाजनक है - क्लाइंट को सर्वर से कनेक्ट करते समय, हम बस AddToGroupAsync API विधि को कॉल करते हैं:

public override async Task OnConnectedAsync() { foreach (var chat in _options.Chats) await Groups.AddToGroupAsync(ConnectionId, chat); await Groups.AddToGroupAsync(ConnectionId, Client); } 

और समूह कैसे छोड़ें? डेवलपर्स एपीआई विधि RemoveFromGroupAsync प्रदान करते हैं:

 public override async Task OnDisconnectedAsync(Exception exception) { foreach (var chat in _options.Chats) await Groups.RemoveFromGroupAsync(ConnectionId, chat); await Groups.RemoveFromGroupAsync(ConnectionId, Client); } 

ध्यान दें कि डेटा यूनिट ConnectionId है। हालाँकि, डोमेन मॉडल के दृष्टिकोण से, ConnectionId मौजूद नहीं है, लेकिन क्लाइंट हैं। इस संबंध में, क्लाइंट का संगठन, कनेक्शनआईडी सरणी के लिए मैपिंग और इसके विपरीत निर्दिष्ट पुस्तकालय के उपयोगकर्ताओं को सौंपा गया है।

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

कनेक्शन के लिए क्लाइंट को मैप करने के तरीके

MSDN पर एक संपूर्ण अनुभाग इस समस्या के लिए समर्पित है। विचार के लिए निम्नलिखित विधियाँ प्रस्तावित हैं:

• इन-मेमोरी स्टोरेज
• "उपयोगकर्ता समूह"
• स्थायी बाहरी संग्रहण

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

उपरोक्त विकल्पों में, "उपयोगकर्ता समूह" विकल्प दिलचस्प है। सादगी निश्चित रूप से इसके फायदे पर लागू होती है - कोई लाइब्रेरी नहीं, रिपॉजिटरी की आवश्यकता होती है। समान रूप से महत्वपूर्ण इस पद्धति की सादगी का परिणाम है - विश्वसनीयता।

"उपयोगकर्ता समूह"

"उपयोगकर्ता समूह" क्या है? यह सिग्नलआर शब्दावली में एक समूह है जहां केवल एक ग्राहक एक ग्राहक हो सकता है - वह खुद। यह 2 चीजों की गारंटी देता है:

1. संदेश केवल एक व्यक्ति को दिए जाएंगे
2. सभी मानव उपकरणों तक संदेश पहुंचाया जाएगा

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

"उपयोगकर्ता-समूह" इस समस्या को हल करने की दिशा में पहला कदम है। दूसरा कदम क्लाइंट पर "मिरर" बनाना है। हां, हां, दर्पण।

आईना

क्लाइंट से सर्वर पर भेजे गए कमांड का स्रोत उपयोगकर्ता क्रियाएं हैं। संदेश पोस्ट करें - सर्वर को कमांड भेजें:

 this.state.hubConnection .invoke('post', {message, group, nick}) .catch(err => console.error(err)); 

और हम नए पोस्ट के बारे में समूह के सभी ग्राहकों को सूचित करते हैं:

 public async Task PostMessage(PostMessage message) { await Clients.Group(message.Group).SendAsync("message", new { Message = message.Message, Group = message.Group, Nick = ClientNick }); } 

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

क्लाइंट से आने वाली टीम पहले एक विशेष विधि के लिए "उपयोगकर्ता समूह" पर जाएगी, जो इसे सर्वर पर वापस भेज देगी, अर्थात। " दर्पण ।" इस प्रकार, सर्वर डिवाइसों को अनसब्सक्राइब नहीं करेगा, लेकिन डिवाइसों को स्वयं ही सदस्यता समाप्त करने के लिए कहा जाएगा।

यहां सर्वर चैट अनसब्सक्राइब कमांड का एक उदाहरण दिया गया है:

 public async Task LeaveChat(LeaveChatMessage message) { await Clients.OthersInGroup(message.Group).SendAsync("lost", new ClientCommand { Group = message.Group, Nick = Client }); await Clients.Group(Client).SendAsync("mirror", new MirrorChatCommand { Method = "unsubscribe", Payload = new UnsubscribeChatMessage { Group = message.Group } }); } 

 public async Task Unsubscribe(UnsubscribeChatMessage message) { await Groups.RemoveFromGroupAsync(ConnectionId, message.Group); } 

और यहाँ ग्राहक कोड है:

 connection.on('mirror', (message) => { connection .invoke(message.method, message.payload) .catch(err => console.error(err)); }); 

आइए अधिक विस्तार से देखें कि यहां क्या हो रहा है:

1. ग्राहक सदस्यता समाप्त करता है - सर्वर को "छुट्टी" कमांड भेजता है
2. सर्वर "अनसब्सक्राइब" कमांड "मिरर ग्रुप" को "मिरर" पर भेजता है
3. संदेश सभी क्लाइंट डिवाइसों को दिया जाता है।
4. क्लाइंट द्वारा एक संदेश सर्वर द्वारा निर्दिष्ट विधि का उपयोग करके सर्वर पर वापस भेजा जाता है
5. प्रत्येक सर्वर पर, क्लाइंट को समूह से सदस्यता समाप्त कर दिया जाता है

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

तो हमें कनेक्ट करने की आवश्यकता क्यों है?

"उपयोगकर्ता समूह" और क्लाइंट पर "दर्पण" होने से कनेक्शन के साथ काम करने की आवश्यकता समाप्त हो जाती है। आपको क्या लगता है, प्रिय पाठकों, इस बारे में? अपनी राय कमेंट में शेयर करें।

उदाहरण के लिए स्रोत कोड:

github.com/aesamson/signalr-server
github.com/aesamson/signalr-client