मेरे पास एक ऐसा एप्लिकेशन है जिसमें दो प्रक्रियाएं होती हैं (चलिए उन्हें ए और बी कहते हैं), यूनिक्स डोमेन सॉकेट के माध्यम से एक दूसरे से जुड़े हुए हैं। अधिकांश समय यह ठीक काम करता है, लेकिन कुछ उपयोगकर्ता निम्न व्यवहार की रिपोर्ट करते हैं:क्या एक अंतहीन कॉलिंग बंद() या क्रैशिंग के बिना एक सहज ईपीआईपीई त्रुटि का कारण बन सकता है?
- ए बी के लिए अनुरोध भेजता है। यह काम करता है। अब बी
- बी से उत्तर पढ़ने शुरू होता है। बी को उत्तर भेजता है। संबंधित लेखन() कॉल एक ईपीआईपीई त्रुटि देता है, और परिणामस्वरूप बी बंद() सॉकेट होता है। हालांकि, ए बंद() सॉकेट, और न ही यह दुर्घटनाग्रस्त हो गया।
- ए पढ़ा गया() कॉल रिटर्न 0, अंत-फ़ाइल का संकेत देता है। एक सोचता है कि बी ने समय से कनेक्शन बंद कर दिया।
उपयोगकर्ताओं को भी इस व्यवहार के रूपांतरों की सूचना दी है, जैसे:
- एक एक अनुरोध बी को यह आंशिक रूप से काम करता है भेजता है, लेकिन पूरे अनुरोध एक के लिखने भेजे जाने से पहले() कॉल EPIPE देता है, और नतीजतन एक करीबी() सॉकेट। हालांकि बी ने सॉकेट को बंद नहीं किया, और न ही यह दुर्घटनाग्रस्त हो गया।
- बी आंशिक अनुरोध पढ़ता है और फिर अचानक एक ईओएफ प्राप्त होता है।
समस्या यह है कि मैं स्थानीय रूप से इस व्यवहार को पुन: उत्पन्न नहीं कर सकता। मैंने ओएस एक्स और लिनक्स की कोशिश की है। उपयोगकर्ता विभिन्न प्रणालियों पर हैं, ज्यादातर ओएस एक्स और लिनक्स।
चीज़ें है कि मैं पहले से ही करने की कोशिश की और माना जाता है:
- डबल पास() कीड़े (करीब() एक ही फाइल वर्णनकर्ता पर दो बार कहा जाता है): शायद नहीं के रूप में है कि EBADF त्रुटियों में परिणाम है, लेकिन होता मैंने उन्हें नहीं देखा है।
- अधिकतम फ़ाइल डिस्क्रिप्टर सीमा को बढ़ा रहा है। एक उपयोगकर्ता ने बताया कि यह उसके लिए काम करता है, बाकी ने बताया कि यह नहीं था।
संभवतः इस तरह के व्यवहार का कारण क्या हो सकता है? मुझे निश्चित रूप से पता है कि न तो ए और बी बंद() सॉकेट को समय-समय पर बंद करते हैं, और मुझे निश्चित रूप से पता है कि उनमें से कोई भी क्रैश नहीं हुआ है क्योंकि ए और बी दोनों त्रुटि की रिपोर्ट करने में सक्षम थे। ऐसा लगता है जैसे कर्नेल ने अचानक किसी कारण से प्लग को सॉकेट से खींचने का फैसला किया।
यह पता चला कि सर्वर की फ़ाइल डिस्क्रिप्टर को EPOLLET ध्वज के साथ एपोल कतार में जोड़ा गया था जो गलत लगता है। – user206268
बिल्कुल वही जवाब नहीं जिसे मैं ढूंढ रहा था लेकिन आपके द्वारा लिंक किया गया टीसीपी पृष्ठ बहुत ही जानकारीपूर्ण है! यह अभी भी Archive.org द्वारा नीचे है: http://ia700609.us.archive.org/22/items/TheUltimateSo_lingerPageOrWhyIsMyTcpNotReliable/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable .html – Hongli