अगर मैं दो टीसीपी संदेश भेजता हूं, तो क्या मुझे उस मामले को संभालने की ज़रूरत है जहां उत्तरार्द्ध पूर्व के सामने आता है? या क्या मैं इसे भेजने के आदेश में आने की गारंटी देता हूं? मुझे लगता है कि यह एक ट्विस्ट-विशिष्ट उदाहरण नहीं है, क्योंकि इसे टीसीपी मानक के अनुरूप होना चाहिए, लेकिन यदि ट्विस्टेड से परिचित कोई भी व्यक्ति अपनी मन की शांति के लिए एक ट्विस्ट-विशिष्ट उत्तर प्रदान कर सकता है, तो इसकी सराहना की जाएगी :-)क्या टीसीपी क्रम में आने की गारंटी है?
जब तक दो संदेश उसी टीसीपी कनेक्शन पर भेजे गए थे, तो आदेश बनाए रखा जाएगा। यदि प्रक्रियाओं की एक ही जोड़ी के बीच कई कनेक्शन खोले जाते हैं, तो आप परेशानी में पड़ सकते हैं।
ट्विस्ट, या किसी अन्य एसिंक्रोनस इवेंट सिस्टम के संबंध में: मुझे उम्मीद है कि बाइट प्राप्त होने के क्रम में आपको dataReceived संदेश मिलेंगे। हालांकि, अगर आप स्थगित कॉल पर काम को धक्का देना शुरू करते हैं, तो आप पहचान सकते हैं ... erm ... मान्यता से परे अपने नियंत्रण प्रवाह को "मोड़"।
टीसीपी एक धारा है, यूडीपी एक संदेश है। आप शब्दों को मिश्रित कर रहे हैं। टीसीपी के लिए यह सच है कि धारा उसी क्रम में पहुंच जाएगी जैसा इसे भेजा गया था। टीसीपी में कोई विकृत संदेश नहीं हैं, बाइट्स आने पर दिखाई देते हैं, उन्हें संदेश के रूप में व्याख्या करना आपके ऊपर है।
पुन: शर्तें - हां, ज़ाहिर है। हालांकि, घुमावदार इसे अलग संदेशों में सार तत्वित करता है (इसलिए उन्हें संदेश के रूप में व्याख्या करना मेरे ऊपर नहीं है) – Smashery
और यह ध्यान देने योग्य है कि प्रेषक पक्ष पर आपके पास दो लिखने के दौरान, वे रिसीवर पक्ष पर एक ही पठन में पतन हो सकते हैं, और उपाध्यक्ष बनाम - बफर आकार और नेटवर्क स्थितियों के आधार पर। –
नहीं, मुड़ता हुआ "संदेश" में टीसीपी सार नहीं है। बेस प्रोटोकॉल में आपको बाइट्स (चरम मामलों में एक समय में एक बाइट तक) का एक हिस्सा मिलेगा। – truppo
टीसीपी कनेक्शन उन्मुख है और इन-ऑर्डर डिलीवरी प्रदान करता है। बेशक यह कनेक्शन स्तर पर लागू होता है: व्यक्तिगत कनेक्शन स्वतंत्र होते हैं।
आपको ध्यान रखना चाहिए कि आम तौर पर हम "टीसीपी धाराएं" और "यूडीपी संदेश" का संदर्भ लेते हैं।
जो भी क्लाइंट लाइब्रेरी आप उपयोग करते हैं (उदा। ट्विस्टेड), अंतर्निहित टीसीपी कनेक्शन इससे स्वतंत्र है। टीसीपी आपके क्लाइंट के लिए "प्रोटोकॉल संदेश" वितरित करेगा। "प्रोटोकॉल संदेश" द्वारा मैं निश्चित रूप से प्रोटोकॉल को संदर्भित करता हूं जो आप टीसीपी परत पर उपयोग करते हैं।
इसके अलावा ध्यान दें कि मैं/हे आपरेशन प्रकृति में async और सिस्टम लोड पर बहुत निर्भर + भी नेटवर्क समझौता कर रहे हैं & नुकसान विलंब, तो आप संदेश के बीच TCP कनेक्शन आदेश देने पर भरोसा नहीं कर सकते हैं।
_between_ टीसीपी कनेक्शन से आपका क्या मतलब है? – simplename
टीसीपी "गारंटी देता है" कि एक रिसीवर को बाइट्स की पुनर्निर्मित धारा प्राप्त होगी क्योंकि इसे मूल रूप से प्रेषक द्वारा भेजा गया था। हालांकि, टीसीपी के बीच अंतराल भेजना/प्राप्त करना (यानी भौतिक नेटवर्क), डेटा को आदेश से बाहर किया जा सकता है, इसे खंडित किया जा सकता है, इसे दूषित किया जा सकता है, और यह भी खोया जा सकता है। इन समस्याओं के लिए टीसीपी खाते हैंडशेक तंत्र का उपयोग करते हैं जो खराब पैकेट को पुनः प्रेषित करने का कारण बनता है। रिसीवर पर टीसीपी स्टैक इन पैकेट को उस क्रम में रखता है जिसमें वे प्रसारित होते थे ताकि जब आप अपने टीसीपी सॉकेट से पढ़ते हैं, तो आपको मूल रूप से भेजा गया डेटा प्राप्त होता है।
जब आप ट्विस्ट में doRead विधि को कॉल करते हैं, तो डेटा को सॉकेट से बफर के आकार तक पढ़ा जाता है। यह डेटा एक संदेश, आंशिक संदेश या एकाधिक संदेशों का प्रतिनिधित्व कर सकता है। बफर से संदेशों को निकालने के लिए आप पर निर्भर है, लेकिन आप इस बात की गारंटी देते हैं कि बाइट इस बिंदु पर उनके प्रेषित क्रम में हैं।
मेरे पहले पोस्ट के साथ जल muddying के लिए क्षमा करें ...
कृपया अपने उत्तर की समीक्षा करें क्योंकि आप बहुत गलत हैं। टीसीपी द्वारा खुलासा एपीआई बाइट आदेशित डिलीवरी के साथ बहुत अधिक स्ट्रीम है। आप यहां अंतर्निहित परिवहन विधि (यानी पैकेट) का जिक्र कर रहे हैं, जो निश्चित रूप से क्रम में आने की गारंटी नहीं है। – jldupont
एफवाईआई, टीसीपी के लिए "सर्वर परत" आईपी है जो निश्चित रूप से "कनेक्शन-कम" है और पैकेट ऑर्डर डिलीवरी की गारंटी नहीं देता है। – jldupont
आप सही हैं। मैं स्पष्ट करूंगा। धन्यवाद। –
के बाद से टीसीपी पता नहीं है, जहां आपके संदेशों शुरू या अंत नहीं है, यह कैसे संभवतः उन्हें पुन: व्यवस्थित कर सकता है, भले ही वह चाहते थे? –