recv सिस्टम कॉल क्यों नहीं है जब तक कि सभी डेटा प्राप्त नहीं हो जाता है? हर बार जब मैंने recv कॉल देखा है, तो यह थोड़ी देर के लूप में है जो सभी डेटा वहां तक recv पर कॉल करता रहता है। क्यों पहले स्थान पर recv ब्लॉक नहीं है?जब तक यह सभी डेटा प्राप्त नहीं करता तब तक रिकॉव ब्लॉक क्यों नहीं करता है?
MSG_WAITALL ध्वज के साथ आप सभी रिकॉर्ड्स प्राप्त होने तक उस आरईवी ब्लॉक का अनुरोध कर सकते हैं। हालांकि, अगर कोई सिग्नल आता है, तो एक सिस्टम कॉल जिसने कुछ काम किया है (यानी, डेटा का हिस्सा प्राप्त करना) शेष प्राप्त करने के लिए स्वचालित रूप से पुनरारंभ नहीं किया जा सकता है। ऐसे में, MSG_WAITALL के साथ भी, ऐसे मामले हैं जहां बफर भरने से पहले आरईवी कॉल वापस आ सकता है, और आपको इन मामलों को संभालने के लिए तैयार रहना चाहिए। यह देखते हुए, कई लोग बस लूप चुनते हैं और MSG_WAITALL जैसे छोटे-छोटे झंडे से परेशान नहीं होते हैं।
क्यों यह डिफ़ॉल्ट रूप से मामला है के रूप में, वहाँ कुछ कारणों से जो मन में आ रहे हैं। उदाहरण के लिए, यदि आप डेटा को बढ़ते हुए डेटा को प्रदर्शित कर रहे हैं, या यदि आप कहीं और इसे प्रॉक्सी कर रहे हैं, या यदि डेटा इतना बड़ा है तो आप पूरी चीज़ को स्मृति में एक बार में बफर नहीं कर सकते हैं। आखिरकार, अगर आप तुरंत फाइल पर लिख रहे हैं, तो क्या आपको परवाह है कि आप इसे 150 लिखने के बजाए 200 लिखते हैं, कहें, 150?
telnet प्रोटोकॉल पर विचार करें, जो उस समय लोकप्रिय था जब बीएसडी सॉकेट एपीआई डिजाइन किया गया था। आपको आम तौर पर एक समय में बाइट्स का एक मुट्ठी भर मिल जाएगा, कोई लंबाई फ़ील्ड नहीं बताती है कि आपको कितना डेटा उम्मीद करनी है, और इसके अलावा आपको उस डेटा को तुरंत प्रदर्शित करने की आवश्यकता है। जब तक आप यहां एक बफर भर नहीं लेते तब तक ब्लॉक करना समझ में नहीं आता है। इसी तरह लाइन-ओरिएंटेड प्रोटोकॉल जैसे एसएमटीपी या आईएमएपी के साथ - आप नहीं जानते कि कमांड तब तक है जब तक आप इसे प्राप्त नहीं कर लेते।recv अक्सर डेटाग्राम सॉकेट के लिए उपयोग किया जाता है, जहां इसे एक एकल डेटाग्राम प्राप्त होता है, भले ही यह बफर से बहुत छोटा हो। सॉकेट स्ट्रीमिंग के लिए प्राकृतिक विस्तार केवल उतना ही वापस लौटना है जितना आप प्रतीक्षा किए बिना कर सकते हैं।लेकिन सबसे महत्वपूर्ण है, क्योंकि आप एक आंशिक बफर वैसे भी से निपटने के लिए तैयार रहने की जरूरत है, यह लोगों को डिफ़ॉल्ट रूप से इससे निपटने के लिए मजबूर करने के लिए अच्छा है, ताकि वे अपने पाश जल्दी में कीड़े बारी - बल्कि एक दुर्भाग्यपूर्ण पल में सिग्नल आने तक उन्हें छुपा रहता है।
ज्यादातर मामलों में, आप नहीं जानते कि डेटा "सभी डेटा" कितना है। उदाहरण के लिए, यदि आप लाइन-उन्मुख प्रोटोकॉल में डेटा प्राप्त कर रहे हैं, तो एक पंक्ति 10 बाइट लंबी या 65 बाइट लंबी हो सकती है।
आप सॉकेट झंडे को या तो अवरुद्ध या गैर-अवरुद्ध करने के लिए बदल सकते हैं। आपके विशिष्ट मामले में वास्तव में अवरुद्ध करने या अवरुद्ध करने के साथ कुछ भी नहीं है।
डिफ़ॉल्ट रूप से वर्णन करने के तरीके में नेटवर्क फ़ंक्शन का व्यवहार करने का कोई अर्थ नहीं होगा - क्या होगा यदि स्ट्रीम कभी समाप्त न हो .. क्या प्रोग्राम कभी खत्म नहीं होना चाहिए? प्राइमा फ्रेसिया, यह स्वस्थ डिफ़ॉल्ट व्यवहार जैसा प्रतीत नहीं होता है।
http://www.scottklement.com/rpg/socktut/nonblocking.html को अवरुद्ध करने और गैर-अवरुद्ध आईओ के साथ स्वयं को परिचित करने के लिए पढ़ें।