आठ बाइट पढ्नुहोस्, त्यसपछि SOCKS4 सुरुङ हस्तान्तरण गर्नुहोस्

SOCKS4 जडान अनुरोध सफल हुन्छ, तर अनुप्रयोगले सर्भरको सुरुवाती अभिवादन कहिल्यै देख्दैन। हेर्नुपर्ने एउटा ठाउँ कनेक्टरको पहिलो पढाइ हो। सोह्र बाइटको पढाइ आठ बाइटको SOCKS4 प्रतिक्रियाका लागि धेरै ठूलो हुन्छ।

नतिजा कोड 0x5a ले अनुरोध स्वीकृत भएको देखाउँछ। SOCKS4a ले अनुरोधले होस्टनाम कसरी बोक्छ भन्ने बदल्छ; यसले प्रतिक्रियालाई सोह्र बाइट बनाउँदैन।

प्रतिक्रियापछि त्यही TCP स्ट्रिमले गन्तव्यको प्रोटोकल बोक्छ। मेल सर्भरले आफ्नो अभिवादन तुरुन्तै पठाउन सक्छ। त्यसैले सोह्र उपलब्ध बाइट खपत गर्ने पढाइले पूरा प्रोक्सी प्रतिक्रिया र त्यस अभिवादनका पहिलो आठ बाइट लैजान सक्छ। यदि अझै केही नआए, धेरै ठूलो ब्लकिङ पढाइले बरु अनावश्यक प्रतीक्षा थप्न सक्छ।

ठ्याक्कै लम्बाइ पार्सरको जिम्मेवारी हो

एक पटक आठ बाइट माग्नु आठ बाइट आएको पर्याप्त प्रमाण होइन। स्ट्रिम पढाइले कम फर्काउन सक्छ। समयसीमाभित्र प्रतिक्रियाको लम्बाइ ठ्याक्कै संकलन गर्नुहोस्, बन्द वा असफल स्ट्रिममा रोक्नुहोस्, प्रतिक्रिया जाँच्नुहोस्, र अर्को बाइट अनुप्रयोगका लागि छोड्नुहोस्।

यदि कनेक्टरले ठूलो बफर पढाइ प्रयोग गर्छ भने सीमापछिको सबै सुरक्षित राख्नुहोस् र अर्को उपभोक्तालाई दिनुहोस्। बढी फाल्नु भनेको फरक पढाइ आकारसँगै त्यही डेटा हानि हो।

SOCKS5 लाई आफ्नै पार्सर चाहिन्छ। यसको प्रतिक्रिया ठेगानाको लम्बाइ ठेगाना प्रकारअनुसार फरक हुन सक्छ। हरेक प्रोक्सी पढाइलाई निश्चित आठ बाइटको पढाइले बदल्नुले एउटा प्रोटोकल सुधार्छ तर अर्को बिगार्छ।