प्रलंबित बाइट्स रिकामे केल्यानंतर TCP हाफ-क्लोज पुढे पाठवणे

क्लायंट पाठवणे संपवतो, प्रॉक्सीला EOF दिसतो, आणि उत्तर गायब होते. प्रॉक्सीचे दोन्ही सॉकेट लगेच बंद केल्यास नेमका तोच क्रम होऊ शकतो. TCP रिलेमध्ये एका दिशेने व्यवस्थित शेवट म्हणजे दुसरी दिशा संपली आहे असा अर्थ नाही.

असा क्लायंट विचारात घ्या जो विनंती पाठवतो, आपली पाठवण्याची बाजू बंद करतो आणि उत्तराची वाट पाहतो:

client -- request, then FIN --> proxy --> service
client <-------- reply ------- proxy <-- service

प्रॉक्सीकडे दोन TCP कनेक्शन आणि स्वतंत्रपणे हलणारे दोन बाइट स्ट्रीम आहेत. त्याने आधी येणारे बाइट्स पुढे पाठवल्यानंतर इनपुटच्या शेवटाचा संकेतही पुढे न्यायचा आहे.

EOF पुढे पाठवण्यापूर्वी रांग रिकामी करा

TCP स्ट्रीमवर शून्य नसलेल्या आकाराच्या प्राप्तीमध्ये, शून्य परत येणे म्हणजे त्या येणाऱ्या स्ट्रीमचा व्यवस्थित शेवट. ती वाचनाची दिशा पूर्ण झाली असे चिन्हांकित करा. त्यातून अधिक इनपुटची वाट पाहणे थांबवा, पण विरुद्ध सॉकेटसाठी आधीच रांगेत असलेले बाइट्स ठेवा.

क्लायंटकडून सेवेकडे जाणारी रांग रिकामी झाल्यावर, POSIX सॉकेटवर shutdown(service_socket, SHUT_WR) कॉल करा. त्यामुळे सेवेकडे जाणारे पुढील प्रसारण थांबते, तर सेवेकडून क्लायंटकडे जाणारी दिशा उपलब्ध राहते. सेवा तिचे उत्तर पूर्ण करते तेव्हा, उत्तराची रांग रिकामी केल्यानंतर आरशासारखी क्रिया लागू करा.

डिस्क्रिप्टर बंद करणे हे त्या टप्प्याशी संबंधित आहे जिथे दोन्ही दिशा आणि त्यांचे प्रलंबित बफर संपले आहेत, किंवा जिथे त्रुटी किंवा रद्दीकरणासाठी समाप्ती आवश्यक आहे. आपला उर्वरित अर्धा भाग कधीही पूर्ण न करणाऱ्या सहभागीसाठी मर्यादित कालमर्यादा ठेवा.

तयारी हे वाचण्याचे निमंत्रण आहे

वाचनीय सॉकेटमध्ये डेटा किंवा EOF स्थिती असू शकते. recv कॉल करा आणि त्याचा निकाल समजून घ्या. धन संख्या पुढे पाठवायचे बाइट्स आहेत; शून्य म्हणजे दिशेचा शेवट. नॉनब्लॉकिंग सॉकेटवर, EAGAIN किंवा EWOULDBLOCK म्हणजे सध्या अधिक इनपुट नाही, तर EINTR ला पुन्हा प्रयत्न करावा लागू शकतो. दोन्हीपैकी कोणतेही EOF सारखी तीच घटना नाही.

परत मिळालेल्या बाइट बफरमध्ये FIN फ्लॅग शोधू नका. TCP या API ला क्रमबद्ध बाइट स्ट्रीम पुरवते; पॅकेट सीमा आणि FIN सेगमेंट हे सामान्य अनुप्रयोग पेलोड नाहीत.

हे कच्च्या बाइट टनेलचे जीवनचक्र आहे. संदेश पार्स करणाऱ्या HTTP प्रॉक्सीने तरीही HTTP फ्रेमिंगचा आदर केला पाहिजे, आणि TLS संपवणाऱ्या प्रॉक्सीमध्येही TLS शटडाउन प्रोटोकॉल असतो. ते प्रोटोकॉल निर्णय दिशात्मक TCP रिलेच्या वर ठेवा.