पेन्डिङ बाइटहरू खाली गरेपछि 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 रिलेमाथि राख्नुहोस्।