रियल टाइम डेटा/मोबाइल उपकरणों के लिए एक नेटवर्क प्रोटोकॉल डिजाइनिंग

Question

मैं एक निम्न दुविधा का सामना करना पड़ रहा हूँ:

डिजाइन एक नया नेटवर्क प्रोटोकॉल है जो एक सर्वर (जावा सॉफ्टवेयर) और डेस्कटॉप और मोबाइल ग्राहकों के बीच किया जाएगा। मोबाइल क्लाइंट में जे 2 एमई, एंड्रॉइड और शायद भविष्य में आईफोन भी शामिल है।

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

यदि संभव हो तो मैं पूरी तरह से कस्टम टीसीपी प्रोटोकॉल कार्यान्वयन को स्क्रैच से बचाना चाहता हूं।

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

मैं गैर-सादे पाठ प्रोटोकॉल पर भी विचार कर रहा हूं (वर्तमान वाले जिन्हें मैं बदल रहा हूं बाइनरी प्रोटोकॉल हैं)। उन मौजूदा प्रोटोकॉल में उनके गंभीर मुद्दे हैं इसलिए उन्हें वास्तव में बदला जाना चाहिए।

Google प्रोटोकॉल बफर निम्न स्तर के विवरणों को संभालने के लिए एक बहुत मजबूत उम्मीदवार की तरह दिखता है, लेकिन मुझे यकीन नहीं है कि इसका उपयोग Android से किया जा सकता है या नहीं। और मुझे पूरा यकीन है कि आईफोन कार्यान्वयन में इसके साथ भी समस्याएं होंगी।

BEEP भी है, लेकिन मुझे लगता है कि यह काफी मर चुका है और मुझे आश्चर्य है कि यह कभी व्यापक रूप से उपयोग किया जाता था।

कोई विचार?

Answer 1

आप RTP (Real-time Transport Protocol) पर देख सकते हैं, जो शायद सीधे उपयोगी नहीं हो सकता है (और/या अधिक हो सकता है), लेकिन इसका डिज़ाइन आपको काम करने के लिए कुछ अच्छे विचार देगा। और आप इसका उपयोग करने में सक्षम हो सकते हैं।

Answer 2

मैं प्रोटोकॉल डिजाइन में हो रही तुम सच में ध्यान से निम्न समस्याओं का ध्यान रखना चाहिए से पहले लगता है:

• लगभग सभी HTTP छोड़कर प्रोटोकॉल इन दिनों फायरवॉल द्वारा फ़िल्टर कर रहे हैं। सेवा प्रदाताओं द्वारा विशेष रूप से मोबाइल डेटा सेवाओं में भी कई सामग्री प्रकार और बंदरगाहों (80 को छोड़कर) फ़िल्टर किया जा सकता है। इसलिए, सुनिश्चित करें कि प्रोटोकॉल का उपयोग या डिजाइन करने से पहले आपके लक्षित नेटवर्क में आपके पास कोई फ़ायरवॉल समस्या नहीं है।
• आकार और गति के मामले। परिवहन संदेश आकार और एनकोड/डीकोड (क्रमबद्ध/deserialize) गति दोनों में कुशल प्रोटोकॉल का उपयोग करने की कोशिश करें। Google Protocol Buffers इस समस्या का एक विश्वसनीय समाधान प्रदान करता है।
• कनेक्शन हमेशा डिस्कनेक्ट होते हैं। आप एनएटी टाइमआउट (डिफ़ॉल्ट रूप से 15 मिनट), प्रोटोकॉल टाइमआउट (टीसीपी के लिए 30 मिनट) और कई मौजूदा नेटवर्क समस्याओं के कारण लंबे समय तक खुला रहने के लिए कनेक्शन पर भरोसा नहीं कर सकते हैं। तो, दूसरे पर प्रोटोकॉल पसंद न करें क्योंकि यह कनेक्शन को खुला रखता है (यह कोशिश कर सकता है, लेकिन कभी सफल नहीं होता है)। दिल की धड़कन भेजना टाइमआउट समस्या के लिए एक अच्छा प्रयास है, लेकिन नेटवर्क डिस्कनेक्ट अभी भी अपरिहार्य है।
• थ्रूपुट मामलों। थ्रूपुट द्वारा, मेरा मतलब है कि समय की अवधि में संसाधित संदेशों की संख्या (जैसे 1 सेकंड)। एसिंक्रोनस प्रोटोकॉल का उपयोग करना जो क्लाइंट को अपना संदेश प्राप्त करने के बाद डिस्कनेक्ट करता है, वास्तव में थ्रूपुट बढ़ाने में मदद करता है।हालांकि परिणाम को धक्का देने के लिए सर्वर से क्लाइंट से जुड़ने पर भरोसा न करें क्योंकि कई ग्राहक एनएटी और फ़ायरवॉल के पीछे हैं जो बाहर से सीधे कनेक्शन से बचते हैं। कनेक्शन को खोलने या परिणाम के लिए सर्वर को मतदान करने का प्रयास करें। वार्तालाप में राज्य से बचने की दूसरी विधि भी है जो अनुप्रयोगों के माध्यम से बढ़ने में मदद करता है क्योंकि ग्राहकों की संख्या बढ़ती है।
• मौजूदा वैन में कोई वास्तविक समय नहीं है। उन लोगों पर भरोसा न करें जो कहते हैं कि उन्होंने मौजूदा वाइड एरिया नेटवर्क प्रोटोकॉल के आधार पर रीयल-टाइम प्रोटोकॉल लागू किया है। आप गैर-वास्तविक समय के शीर्ष पर रीयल-टाइम प्रोटोकॉल को कभी भी कार्यान्वित नहीं कर सकते हैं। आप बस अपना सर्वश्रेष्ठ कर सकते हैं और तेजी से जाने के लिए नेटवर्क के लिए प्रार्थना कर सकते हैं। इसका मतलब है: रुको मत, अपना सर्वश्रेष्ठ करो।
• गैर-अवरुद्ध आईओ। एनआईओ (गैर-अवरुद्ध आईओ) अब प्रवृत्ति है, जिसका प्रभावी ढंग से नेटवर्क प्रोग्रामिंग में उपयोग किया जा रहा है। यह कम स्मृति उपयोग और सीमित संख्या में धागे के साथ कनेक्शन की बड़ी संख्या को सक्षम बनाता है। जावा 5 में एनआईओ के लिए मूल समर्थन है जो बहुत ही प्राचीन है। Apache MINA और Netty जैसे कई ढांचे, गैर-अवरुद्ध प्रोग्रामिंग को आसान और अधिक मजबूत बनाने के लिए जावा एनआईओ के आधार पर कार्यान्वित किए गए हैं। मैं दृढ़ता से उन्हें अनुशंसा करता हूं।

Answer 3

आप Kryo और/या KryoNet देख सकते हैं, जो एनआईओ और जावा-आधारित हैं और डेस्कटॉप और एंड्रॉइड काम करते हैं। हालांकि आपको आईफोन की तरफ लिखना होगा, जो कि मुश्किल होगा। क्रियो धारावाहिक आकार (benchmarks here) में Google के प्रोटोकॉल बफर को धड़कता है और उपयोग की आसानी (नहीं। प्रोोटो टाइप स्कीमा को लिखा जाना चाहिए, जावा क्लास परिभाषाएं स्कीमा हैं)।

एनआईओ के संबंध में, आप NPTL देख सकते हैं। बूढ़ा नया फिर से बन जाता है।

Answer 4

यह एक सुरुचिपूर्ण समाधान नहीं है, लेकिन आप HTTP प्रतिक्रिया पर सामग्री-लंबाई फ़ील्ड सेट न करके, और आउटपुट स्ट्रीम को कभी भी बंद न करके सीधे http पर कर सकते हैं। बस डेटा भेजते रहें।

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

दुर्भाग्यवश मुझे इन विचारों के लिए कोई उपयोगी लिंक नहीं मिला, लेकिन मुझे विश्वास है कि आप विचार प्राप्त करते हैं।

इन विचारों का असली प्लस पक्ष यह है कि वे http है, जो फ़ायरवॉल समस्या से हो जाता है से अधिक हैं, और आप एक सर्वलेट के साथ एक webapp रूप में अपने अनुप्रयोग को लागू कर सकते हैं।

बस मेरे 2 सेंट;)