ओके के रूप में। कहते हैं, कई लंबित BeginSend कॉल ठीक काम करेंगे। हालांकि आपको शायद कुछ चीजों को ध्यान में रखना होगा।
सबसे पहले अगर यह एक टीसीपी सॉकेट है तो यह अभी भी सहकर्मी से पीयर तक डेटा की एक धारा है।
दूसरा अगर आपके सभी BeginSend कॉल एक ही थ्रेड पर होते हैं तो परिणाम यह होगा कि सहकर्मी कॉल के क्रम में डेटा प्राप्त करता है। यदि आपकी BeginSend कॉल अलग-अलग धागे से होती हैं तो डेटा किसी भी क्रम में पहुंच सकता है क्योंकि प्रत्येक भेजने के बीच दौड़ की स्थिति होगी। यह आपके लिए महत्वपूर्ण हो सकता है या इससे कोई फर्क नहीं पड़ता (निर्भर करता है कि क्या आप अलग-अलग भेज रहे हैं, प्रत्येक प्रेषण के साथ संदेश पूरा करें या नहीं)।
तीसरा यदि आप टीसीपी का उपयोग कर रहे हैं और सॉकेट के दूसरे छोर पर कोड से तेज़ी से भेजना प्राप्त कर सकते हैं तो आप टीसीपी विंडो भर सकते हैं और टीसीपी स्टैक आपके डेटा स्ट्रीम पर प्रवाह नियंत्रण करने लगेंगे। यदि आप BeginSend कॉल जारी करना जारी रखते हैं तो आप ऐसी परिस्थिति में समाप्त हो सकते हैं जहां आपके कॉलबैक को आपके सर्वर कतार डेटा पर टीसीपी स्टैक के रूप में लंबे समय तक और लंबे समय तक कॉल करने के लिए कहा जाता है (आपको डेटा भेजने के बाद ही कॉलबैक मिल जाता है और टीसीपी विंडो आधारित प्रवाह नियंत्रण नए डेटा को तब तक रोका जा रहा है जब तक कि टीसीपी विंडो अब 'पूर्ण' न हो, यानी पीयर ने in flight के कुछ डेटा के लिए एसीके भेजा है)।
आप तब एक स्थिति में आ सकते हैं जिससे आप एक अनियंत्रित तरीके से भेजने की मशीन पर संसाधनों का उपयोग कर रहे हैं (आप BeginSend जारी करते हैं और यह नहीं पता कि यह कब पूरा होगा और प्रत्येक प्रेषण बफर को भेजा जा सकता है और संभावित रूप से स्मृति का उपयोग करता है non-paged pool विंसॉक कोड में नीचे ... Non-paged pool एक सिस्टम विस्तृत संसाधन है और प्री विस्टा ओएस पर काफी दुर्लभ है और कुछ बुरी तरह से व्यवहार किए गए ड्राइवर बॉक्स को नीली स्क्रीन कर सकते हैं यदि non-paged pool कम या थका हुआ है। आप और भी पेज लॉक कर सकते हैं मेमोरी में मेमोरी और लॉक मेमोरी पेजों की संख्या पर एक और सिस्टम की विस्तृत सीमा है।
इन मुद्दों के कारण आमतौर पर अपने प्रोटोकॉल स्तर प्रवाह को लागू करना सबसे अच्छा होता है नियंत्रण जो BeginSend कॉल की संख्या को सीमित करता है जिसे किसी भी समय लंबित किया जा सकता है (प्रोटोकॉल स्तर एसीके का उपयोग करके) या टीसीपी विंडो प्रवाह नियंत्रण के साथ काम करने के लिए और एक नया प्रेषण जारी करने के लिए लंबित प्रेषण के पूरा होने का उपयोग करें और आप कर सकते हैं कतार डेटा अपनी याद में भेजने के लिए और संसाधनों पर पूर्ण नियंत्रण है और यदि आप "बहुत अधिक" डेटा कतार करते हैं तो आप क्या करते हैं। इस बारे में अधिक विस्तार के लिए यहाँ अपने ब्लॉग पोस्ट देखें: http://www.serverframework.com/asynchronousevents/2011/06/tcp-flow-control-and-asynchronous-writes.html
इस का उत्तर देखें: टीसीपी विंडो प्रवाह नियंत्रण के बारे में अधिक जानकारी के लिए what happens when tcp/udp server is publishing faster than client is consuming? और क्या ओवरलैप आई/ओ के साथ होता है (C++ भूमि) जब आप इसे अनदेखा और इस मुद्दे को भी कई ओवरलैप भेजता है ...
संक्षेप में, एकाधिक समवर्ती BeginSend कॉल पोस्ट करना इष्टतम टीसीपी डेटा प्रवाह का तरीका है, लेकिन आपको यह सुनिश्चित करने की ज़रूरत है कि आप "बहुत तेज" नहीं भेजते हैं क्योंकि एक बार जब आप संसाधनों का उपभोग कर रहे हैं जिस तरीके से आप नियंत्रित नहीं कर सकते हैं और जो मशीन आपके कोड पर चल रही है, उसके लिए संभावित रूप से घातक है। इसलिए BeginSend कॉल की असंबद्ध संख्या को बकाया होने की अनुमति न दें और आदर्श रूप से, यह सुनिश्चित करने के लिए बॉक्स को प्रोफ़ाइल दें कि आप सिस्टम व्यापक संसाधनों को थकाऊ नहीं कर रहे हैं।
स्रोत
2010-02-18 13:31:05
@ लेंस, यह एक अच्छा एक +1 है –
@ लेंस: मेरे पास प्रोटोकॉल में बनाया गया खिड़की है जो मैं भेज रहा हूं (smpp) ताकि वे कभी भी तेजी से भेजने की बात न हों। आपके द्वारा उठाए गए आदेश बिंदु से बाहर एक मुद्दा होगा। – Toad
@ लेन, उपरोक्त मेरी टिप्पणी में आपका नाम गलत वर्तनी, मेरी माफी :) –