डेटा ट्रांसफर प्रोटोकॉल के बारे में

इस लेख में मैं अपने व्यक्तिगत, गैर-शैक्षणिक, विभिन्न बंद डेटा ट्रांसफर प्रोटोकॉल के साथ काम करने का अनुभव (मुख्य रूप से एप्लिकेशन-सत्र के चरणों में) साझा करना चाहता हूं।

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

क्या गुण और विशेषताएं एक अच्छा, उपयुक्त सक्षम, उच्च गुणवत्ता वाला प्रोटोकॉल है?

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

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

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

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

बेशक, कुछ कार्यों के लिए , प्रतीकात्मक प्रोटोकॉल हैं, यदि सबसे प्रभावी नहीं है, तो कम से कम एक पूरी तरह से स्वीकार्य विकल्प है, लेकिन हम आगे बढ़ेंगे।

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

संदेश के आकार (असतत बाइट पैकेट जिसे पिछले और बाद में प्राप्त डेटा से स्वतंत्र रूप से संसाधित किया जा सकता है) निश्चित और परिवर्तनशील हैं । यह स्पष्ट है कि एक निश्चित संदेश आकार के साथ, सब कुछ सरल है - एक निश्चित संख्या में बाइट को हेडर से शुरू करके (इसके बारे में बाद में) घटाया जाता है और प्रसंस्करण के लिए भेजा जाता है। अक्सर लचीलेपन प्रदान करने के लिए, ऐसे प्रोटोकॉल के ड्राफ्ट में संदेश शामिल होता है जो एक निश्चित आकार के क्षेत्र (कभी-कभी कुल का 80% तक) वर्तमान प्रोटोकॉल के संशोधनों के लिए आरक्षित होता है। मेरी राय में, यह लचीलापन सुनिश्चित करने का सबसे प्रभावी तरीका नहीं है, लेकिन अभी भी कुछ अतिरेक है।
चर लंबाई के संदेशों पर विचार करें।
यहां आप पहले से ही किसी भी प्रोटोकॉल में बाइनरी संदेश के अपरिहार्य विशेषता के बारे में अधिक विस्तार से बात कर सकते हैं - हेडर के बारे में (यह कंटेनर का पूर्वोक्त स्तर है)।
आमतौर पर, हेडर एक निरंतर बाइट स्ट्रीम में संदेश की शुरुआत का पता लगाने के लिए, एक निश्चित संभावना के साथ, एक निरंतर भाग के साथ शुरू होता है। जाहिर है, बाइट्स की एक मनमानी धारा में इस तरह के लगातार दिखाई देने का खतरा होता है, और यद्यपि वॉल्यूम में वृद्धि इस जोखिम को कम करती है (मैं 0123456789VASIA9876543210 जैसे स्थिरांक से मिला), यह चेकसम गणना के आधार पर चेक का उपयोग करने के लिए अधिक समीचीन है।
निरंतरता आमतौर पर प्रोटोकॉल के संस्करण संख्या के बाद होती है, जो हमें यह समझने की अनुमति देती है कि आगे पढ़ने के लिए किस प्रारूप में होना चाहिए (और क्या हमारे पास इस संदेश को संसाधित करने की क्षमता है - अचानक यह संस्करण हमारे लिए अज्ञात है)। हेडर का अगला महत्वपूर्ण हिस्सा: कंटेनर की सामग्री के बारे में जानकारी। सामग्री का प्रकार इंगित किया गया है (वास्तव में, डेटा परत के लिए समान प्रोटोकॉल संस्करण संख्या), इसकी लंबाई और चेकसम। इस जानकारी के होने पर, आप पहले से ही सामग्री पढ़ सकते हैं और समस्याओं और आशंकाओं के बिना इसके विश्लेषण के साथ आगे बढ़ सकते हैं।
लेकिन तुरंत नहीं! शीर्षक में इसका एक चेकसम शामिल होना चाहिए ( चेकसम को छोड़कर, गणना से, बिल्कुल ) - केवल इस तरह से हम यह सुनिश्चित कर सकते हैं कि हम केवल बकवास नहीं मानते थे, लेकिन एक वैध हेडिंग, हमारे लिए इरादा डेटा द्वारा पीछा किया। क्या चेकसम मेल नहीं हुआ? हमें एक नई हेडिंग डाउनस्ट्रीम की अगली शुरुआत के लिए देखना होगा ...

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

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

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