सॉकेट प्रोटोकॉल बुनियादी बातों

Question

हाल ही में, एक Socket Programming HOWTO निम्न अनुभाग मुझ पर बाहर कूद गया पढ़ते समय:

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

इस अनुभाग में बताया सॉकेट "प्रोटोकॉल" संदेशों पारित करने के लिए लिखा जा सकता है के लिए 4 संभावनाओं पर प्रकाश डाला गया। मेरा सवाल है, वास्तविक अनुप्रयोगों के लिए उपयोग करने के लिए पसंदीदा तरीका क्या है?

क्या यह लेख आम तौर पर प्रत्येक संदेश (संभवतः शीर्षलेख में) के साथ संदेश आकार शामिल करना सबसे अच्छा है, क्योंकि लेख कम या ज्यादा आवेषण करता है? क्या ऐसी कोई परिस्थितियां हैं जहां एक और तरीका बेहतर होगा?

Answer 1

सामान्य प्रोटोकॉल या तो शीर्षलेख में लंबाई निर्दिष्ट करते हैं, या सीमित हैं (उदाहरण के लिए HTTP, जैसे)।

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

Answer 2

ये वास्तव में टीसीपी के साथ हमारे विकल्प हैं। HTTP, उदाहरण के लिए,, तीसरे, और आगे विकल्प (डबल नई लाइन समाप्त होता अनुरोध/प्रतिक्रिया हेडर, जो पराक्रमContent-Length शीर्षक शामिल या संकेत मिलता है एन्कोडिंग chunked है, या यह Connection: close कहना और नहीं दे सकता है दूसरे के एक मिश्रण का उपयोग करता आप सामग्री की लंबाई लेकिन उम्मीद करते हैं कि आप ईओएफ पढ़ने पर भरोसा करें।)

मैं तीसरा विकल्प पसंद करता हूं, यानि आत्म-वर्णन संदेश, हालांकि उपयुक्त होने पर निश्चित लंबाई सरल है।

Answer 3

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

Answer 4

यदि आप अपना प्रोटोकॉल डिज़ाइन कर रहे हैं तो पहले अन्य लोगों के काम को देखें; वहां पहले से कुछ ऐसा ही हो सकता है जिससे आप या तो 'जैसा है' या पुनर्व्यवस्थित और समायोजन कर सकें। उदाहरण के लिए; वित्तीय txns के लिए ISO-8583, HTTP या POP3 सभी चीजें अलग-अलग होती हैं लेकिन काम करने के लिए साबित होती हैं ... असल में इन चीजों को देखने के लायक है, क्योंकि आप इस बारे में बहुत कुछ सीखेंगे कि असली दुनिया प्रोटोकॉल कैसे एक साथ रखे जाते हैं।

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

Answer 5

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

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