टूटी हुई पाइप त्रुटि का क्या कारण है?

Question 1

मुझे पता है कि पीयर साइड पर सॉकेट बंद होने पर टूटी हुई पाइप एरर को फेंक दिया जाता है।

लेकिन, मेरे परीक्षण में मैंने नोट किया है कि इस तरफ एक तत्काल 'भेजें' कॉल जब सहकर्मी पक्ष बंद होता है तो हमेशा टूटी हुई पाइप त्रुटि नहीं होती है।

उदाहरण के लिए:

पीयर साइड पर सॉकेट बंद करने के बाद (मैंने पीयर को मारकर क्लोज कॉल को असामान्य रूप से बंद करने की कोशिश की है और पीलर को मारकर असामान्य समापन किया है), अगर मैं 40 बाइट भेजने की कोशिश करता हूं, तो मुझे एक टूटी हुई पाइप नहीं मिलती है, लेकिन, अगर मैं कोशिश करता हूं 40000 बाइट भेजें तो यह तुरंत टूटी हुई पाइप त्रुटि देता है।

क्या वास्तव में टूटे हुए पाइप का कारण बनता है और क्या इसका व्यवहार किया जा सकता है?

Question 2

करीब से देखे जाने वाले नेटवर्क के लिए समय लग सकता है - कुल समय लगभग 2 मिनट (हाँ, मिनट!) पोर्ट के लिए पैक किए गए भाग्य के बंद होने से पहले लगभग सभी मृत माना जाता है। कुछ बिंदु पर त्रुटि की स्थिति का पता लगाया जाता है। एक छोटे से लेखन के साथ, आप सिस्टम के MTU के अंदर हैं, इसलिए संदेश भेजने के लिए कतारबद्ध है। एक बड़े लेखन के साथ, आप एमटीयू से बड़े हैं और सिस्टम समस्या को तेज करता है। यदि आप SIGPIPE सिग्नल को अनदेखा करते हैं, तो फ़ंक्शन टूटे हुए पाइप पर EPIPE त्रुटि लौटाएंगे - किसी समय कनेक्शन के टूटे-नेस का पता चलने पर।

Question 3

एक सॉकेट की वर्तमान स्थिति 'कीप-लाइव' गतिविधि द्वारा निर्धारित की जाती है। आपके मामले में, यह संभव है कि जब आप sendकॉल जारी कर रहे हों , तो keep-aliveगतिविधि बताती है कि सॉकेट सक्रिय है और इसलिए sendकॉल बफर में आवश्यक डेटा (40 बाइट्स) लिखेगा और बिना कोई त्रुटि दिए वापस आ जाएगा।

जब आप एक बड़ा हिस्सा भेज रहे हैं, तो कॉल कॉल अवरुद्ध स्थिति में जाती है।

भेजें मैन पेज भी इसकी पुष्टि करता है:

जब संदेश सॉकेट के भेजने वाले बफर में फिट नहीं होता है, तो सामान्य रूप से ब्लॉक करें () भेजें, जब तक कि सॉकेट को गैर-अवरुद्ध I / O मोड में नहीं रखा गया हो। गैर-अवरुद्ध मोड में यह इस मामले में ईएएनजीएन लौटाएगा

इसलिए, मुफ्त उपलब्ध बफर के लिए अवरुद्ध करते समय, यदि कॉलर को अधिसूचित किया जाता है (रख-रखाव तंत्र द्वारा) कि दूसरा छोर अब मौजूद नहीं है, तो कॉल कॉल विफल हो जाएगी।

उल्लिखित जानकारी के साथ सटीक परिदृश्य का अनुमान लगाना कठिन है, लेकिन मेरा मानना है कि यह आपकी समस्या का कारण होना चाहिए।

Question 4

हो सकता है कि 40 बाइट्स पाइप बफर में फिट हों, और 40000 बाइट्स न हों?

संपादित करें:

जब आप किसी बंद पाइप पर लिखने का प्रयास करते हैं तो भेजने की प्रक्रिया को एक संकेत संकेत भेजा जाता है। मुझे पता नहीं है कि सिग्नल कब भेजा जाता है, या पाइप बफर का इस पर क्या प्रभाव पड़ता है। आप सिगनेशन कॉल के साथ सिग्नल को फंसाकर पुनर्प्राप्त करने में सक्षम हो सकते हैं।

Question 5

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

Question 6

नया नेटवर्क डालने के बाद हमें ब्रोकन पाइप त्रुटि हुई। यह सुनिश्चित करने के बाद कि पोर्ट 9100 खुला था और प्रिंटर को टेलनेट पोर्ट 9100 पर कनेक्ट कर सकता था, हमने प्रिंटर ड्राइवर को "एचपी" से "जेनेरिक पीडीएफ" में बदल दिया, टूटी हुई पाइप त्रुटि चली गई और सफलतापूर्वक प्रिंट करने में सक्षम थे।

(आरएचईएल 7, प्रिंटर रिकोह ब्रांड थे, एचपी कॉन्फ़िगरेशन पिछले नेटवर्क पर पहले से मौजूद और कार्यात्मक था)