एक एप्लिकेशन प्रोटोकॉल को डिजाइन करना

Question

मेरे पास एक मौजूदा स्टैंडअलोन एप्लिकेशन है जो नेटवर्क प्रोटोकॉल का उपयोग करके किसी तृतीय पक्ष द्वारा विस्तारित किया जा रहा है। क्षमताओं को पहले ही लागू कर दिया गया है, मुझे बस उन्हें बाहर निकालने की ज़रूरत है।

मानते हैं कि परिवहन प्रोटोकॉल पहले से ही चुना गया है (यूडीपी), क्या कोई संसाधन है जो मुझे मेरे एप्लिकेशन प्रोटोकॉल को डिजाइन करने में मदद करेगा?

सॉफ्टवेयर डिज़ाइन के बारे में बहुत सारी जानकारी प्रतीत होती है, लेकिन प्रोटोकॉल डिज़ाइन पर नहीं। मैंने पहले से ही Application Protocol Design देखा है।

Answer 1

;-p पक्षपातपूर्ण हो सकता है Jabber protocols design guidelines और RFC 4101 देखें। हालांकि इसका उद्देश्य समीक्षाकर्ताओं को आरएफसी को समझना अधिक आसान बनाना है, यह आरएफसी कुछ रोचक सलाह प्रदान करता है।

Answer 2

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

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

फिर आपको संदेशों और प्रतिक्रियाओं को एन्कोड करने का कोई तरीका चाहिए। चारों ओर कई आरपीसी प्रोटोकॉल हैं। आप एसओएपी देख सकते हैं, या एक कस्टम एक्सएमएल आधारित प्रोटोकॉल, या एक बाइनरी डिजाइन कर सकते हैं।

Answer 3

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

दुर्भाग्य से यूडीपी और एसओएपी अपने बचपन में फंस गया प्रतीत होता है, HTTP का सबसे अधिक उपयोग किया जाता है।

Answer 4

यदि आप एक्सएमएल चुन रहे हैं तो ध्यान रखें कि आपके पास मार्कअप का विशाल ओवरहेड होगा।

एक साधारण बाइनरी प्रोटोकॉल को xml की तुलना में पार्स करने के लिए बहुत अधिक संसाधनों की आवश्यकता नहीं होगी।

Answer 5

क्या आपने Google Protocol Buffer पर देखा है? यह इस मुद्दे को हल करने के लिए एक अच्छा तरीका लगता है।

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

Answer 6

मेरे पास एक मौजूदा स्टैंडअलोन एप्लिकेशन है जो नेटवर्क प्रोटोकॉल का उपयोग करके किसी तृतीय पक्ष द्वारा विस्तारित किया जा रहा है।

यह आपके कार्यक्रम के बारे में और इन तृतीय पक्ष एक्सटेंशन की प्रकृति के बारे में कुछ और जानने में मदद करेगा। शायद यूडीपी का उपयोग करने के लिए कुछ तर्क?

Answer 7

protocol buffers के लिए एक और सिफारिश - कम प्रयास के साथ अच्छी तंग बाइनरी। नोट, हालांकि, बाइनरी प्रोटोकॉल अच्छी तरह से परिभाषित किया गया है, फिर भी एक सहमत आरपीसी मानक (several are in progress, टीसीपी या HTTP की तरफ झुकाव करने के लिए नहीं है)।

spec different architectures में क्लाइंट और सर्वर रखना बहुत आसान बनाता है, जो कि अच्छा है - साथ ही यह एक्स्टेंसिबल है।

चेतावनी: मैं .NET versions में से एक के लेखक हूँ, इसलिए मैं अच्छी तरह से

Answer 8

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

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

संक्षेप में, जब भी संभव हो, लीवरेज पहले से मौजूद है।