वह पक्ष जिसने कनेक्शन बंद करने की शुरुआत की है वह वह है जो TIME_WAIT
स्थिति में समाप्त होता है। read()
लौटने वाला 0 इंगित करता है कि सर्वर ने सॉकेट को पहले बंद कर दिया है, इसलिए हाँ - इसका मतलब यह होना चाहिए कि TIME_WAIT
सर्वर की तरफ समाप्त होता है, और ग्राहक LAST_ACK
से गुजरता है।
दिन के अंत में, आप TIME_WAIT
स्थिति से बच नहीं सकते हैं। यहां तक कि यदि आप इसे क्लाइंट से सर्वर पक्ष में ले जाने में सफल होते हैं, तो भी आप (server host, server port, client host, client port)
टुपल का पुन: उपयोग नहीं कर सकते हैं जब तक कि TIME_WAIT
खत्म नहीं हो जाता है (भले ही यह किस तरफ है)।
के बाद से है कि टपल के तीन भाग अपने परिदृश्य (server host
, server port
, client host
) में तय कर रहे हैं, तो आप वास्तव में केवल इन विकल्प हैं: अधिक ग्राहक बंदरगाहों उपलब्ध बनाने के लिए
प्रयास करें। कुछ ऑपरेटिंग सिस्टम डिफ़ॉल्ट रूप से "क्षणिक बंदरगाहों" के लिए उपलब्ध बंदरगाहों की एक छोटी सी श्रृंखला का उपयोग करते हैं (मुझे इस संबंध में ओएसएक्स के बारे में निश्चित नहीं है)। यदि ऐसा है, तो देखें कि क्या आप ओएस में कॉन्फ़िगरेशन ट्वीक के साथ रेंज बदल सकते हैं, या वैकल्पिक रूप से कनेक्शन काम करने तक लूप में bind()
/connect()
के साथ एक कार्यशील पोर्ट के लिए एप्लिकेशन खोज कर सकते हैं।
अपने क्लाइंट पर एकाधिक आईपी पते का उपयोग करके client host
मानों की संख्या का विस्तार करें। आपको विशेष रूप से हालांकि इन आईपी पते में से एक को bind()
आवेदन करना होगा।
सर्वर पर एकाधिक बंदरगाहों और/या आईपी पते का उपयोग करके server host
/server port
मानों की संख्या का विस्तार करें। क्लाइंट को कनेक्ट करने के लिए एक को चुनना होगा (राउंड रॉबिन, यादृच्छिक, आदि)।
शायद यह सबसे अच्छा विकल्प है, यदि यह करने योग्य है: अपने प्रोटोकॉल को दोबारा दोहराएं ताकि कनेक्शन समाप्त हो जाएं, लेकिन एक "निष्क्रिय" स्थिति में जाएं ताकि उन्हें बाद में फिर से उपयोग किया जा सके, बजाय नया कनेक्शन (जैसे HTTP को जीवित रखें)।
sidenote: जब पढ़ा रिटर्न 0 errno मूल्य अपरिभाषित है - errno केवल विफलता के बाद परिभाषित किया गया है। –