WebSockets। विकास और संचालन में कुछ अनुभव। हम क्लाइंट को संशोधित करते हैं

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

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

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

चयनित के रूप में, मैं अपाचे पुस्तकालयों का उपयोग कर एक मॉड्यूल पर बस गया। विशेष रूप से, ये:

• अपाचे-mime4j कोर-0.7.2.jar;
• httpclient-4.2.1.jar;
• httpcore-4.2.1.jar;
• httpmime-4.2.1.jar।

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

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

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

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

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

इसलिए मैंने एक नया प्रोजेक्ट बनाया, और आवश्यक कक्षाएं जोड़ना शुरू किया। और अंत में यह निकला कि सफल संकलन के लिए 32 वर्गों को बाहर निकालना आवश्यक है। और फिर भी, हाँ, परियोजना ने काम किया। सब कुछ सांस ले रहा था। वेब सॉकेट सेवा का कनेक्शन सफल रहा। और सबकुछ ठीक हो जाएगा, लेकिन निम्नलिखित घटना पर ध्यान दिया, जो मेरे लिए समझ से बाहर है। कनेक्शन बंद करते समय, कनेक्शन के लिए जिम्मेदार मॉड्यूल ने एक अपवाद को फेंक दिया:

java.io.EOFException
java.io.ata.DataInputStream.readByte (DataInputStream.java:77) पर
com.example.wsci.HybiParser.start (HybiParser.java:112) पर
com.example.wsci.WebSocketClient $ 1.run (WebSocketClient.java:144) पर
java.lang.Thread.run (Thread.java:818) पर

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

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

दूसरी चीज जिसने मुझे सब कुछ फिर से लिखना चाहा, वह थी पार्सर की संरचना। इस ऑब्जेक्ट (क्लास) को सर्वर से ट्रांसमिशन के लिए डेटा पैकेट बनाने और सर्वर से प्राप्त पैकेट के पार्सिंग के लिए दो मुख्य कार्यों को पूरा करना चाहिए। तो, यह ये दो कार्य थे जो सूट नहीं करते थे, बड़े और बड़े। और यहाँ बात है।

कल्पना कीजिए कि एक नेटवर्क घटना हुई है, एक पैकेट आ गया है। इस मामले में HybiParser ने क्या किया? यह ऑब्जेक्ट बाइट द्वारा सॉकेट के इनपुट स्ट्रीम से पहले दो बाइट्स को पढ़ता है और अपने अगले कार्यों को निर्धारित करता है: डेटा आकार, मुखौटा, आदि को पार्स करना। नतीजतन, यह सॉकेट के इनपुट स्ट्रीम से कई रीड ऑपरेशंस में लागू किया गया था। इसके अलावा, पार्सिंग को चरणों को पढ़कर जटिल किया गया था, जो एल्गोरिथ्म को और जटिल बनाता है। और फिर से सवाल उठा, क्या यह सही है, ऐसी कठिनाइयाँ क्यों? क्या एक पैकेट को एक ऑपरेशन मानना ​​बेहतर नहीं है, खासकर जब से आने वाले डेटा का आकार निर्धारित किया जा सकता है?

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

इन सभी बारीकियों के मूल्यांकन के परिणामस्वरूप, आवश्यक मॉड्यूल के डिजाइन के लिए निम्नलिखित आवश्यकताओं को निर्धारित किया गया था:

• मॉड्यूल तीसरे पक्ष के पुस्तकालयों से स्वतंत्र होना चाहिए;
• मॉड्यूल अन्य परियोजनाओं में एकीकृत करने के लिए सरल और आसान होना चाहिए;
• भविष्य के कार्यात्मक विस्तार के लिए मॉड्यूल तैयार होना चाहिए।

ठीक है, और इसलिए पिछले तैयार समाधान की अत्यधिक आलोचना के लिए दोषी नहीं ठहराया जा सकता है, हम इसके अतिरिक्त जोड़ते हैं कि तैयार और गैर-आलोचना वाले कार्यों का हिस्सा सुरक्षित रूप से एक नए कार्यान्वयन में स्थानांतरित किया जा सकता है। ठीक है, यह सब और जैसा कि उन्होंने CPSU के XXII कांग्रेस में कहा था: “हमारे लक्ष्य स्पष्ट हैं, कार्य परिभाषित हैं। काम करने के लिए, कामरेड! साम्यवाद की नई जीत के लिए! "

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

• WebSocket प्रोटोकॉल 07 वैश्विक स्थिरांक मॉड्यूल;
• हेल्पर अपवाद वर्ग;
• वेब सॉकेट क्लाइंट;
• WebSocket प्रोटोकॉल स्तर 07 के पैकेट को पार्स करने के लिए मॉड्यूल।

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

अगला, पैकेट लूप नियंत्रण कार्यों पर ध्यान दें। सिंक्रनाइज़ेशन ऑब्जेक्ट के माध्यम से कार्यान्वयन तुच्छ है।

सम्मान पाने वाला अगला बिंदु लूप का कार्य है। चक्र "शाश्वत" नहीं है, लेकिन सिंक्रनाइज़ेशन ऑब्जेक्ट की जांच करने की शर्त के तहत बाहर निकलने के साथ है। एक चक्र में, एक आने वाले पैकेट को एक ऑपरेशन में पढ़ा जाता है। पैकेज को पार्सिंग के लिए संबंधित वस्तु द्वारा पार्स किया जाता है। अगला, आगामी नेटवर्क इवेंट पर एक प्रबंधन निर्णय लिया जाता है।

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

WebSocket पैकेट के विश्लेषण को लागू करने वाले वर्ग में दो विधियाँ हैं जिन पर ध्यान देने की आवश्यकता है: स्वयं को पार्स करना और संबंधित मापदंडों के अनुसार संचरण के लिए एक पैकेट का निर्माण। पार्स करते समय, प्राप्त पैकेट से सभी झंडे और डेटा सार्वजनिक, वर्ग चर में संग्रहीत किए जाते हैं। सार्वजनिक क्यों? हां, सादगी के लिए, ताकि उनके लिए अतिरिक्त गेट / सेट फ़ंक्शन न बनाएं।

खैर, वास्तव में, प्रिय पाठक। एंड्रॉइड स्टूडियो के प्रोजेक्ट के साथ संग्रह संलग्न है । मैं आपकी परियोजनाओं में इन ग्रंथों के उपयोग का कोई दावा नहीं करूंगा। रचनात्मक आलोचना स्वीकार की जाती है। जहाँ तक हो सके सवालों के जवाब दें।