आठ बाइट पढ़ें, फिर SOCKS4 सुरंग सौंप दें

SOCKS4 प्रतिक्रिया की निश्चित सीमा का विश्लेषण करके गंतव्य के अभिवादन को निगलने या अनुपस्थित बाइट का इंतज़ार करने से बचें।

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

प्रतिक्रिया फ़ील्डबाइट
प्रतिक्रिया संस्करण फ़ील्ड1
परिणाम कोड1
पोर्ट फ़ील्ड2
पता फ़ील्ड4

परिणाम कोड 0x5a दर्शाता है कि अनुरोध स्वीकृत हुआ। SOCKS4a बदलता है कि अनुरोध होस्टनाम कैसे ढोता है; यह प्रतिक्रिया को सोलह बाइट नहीं बनाता।

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

सटीक लंबाई पार्सर की ज़िम्मेदारी है

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

अगर कनेक्टर बड़ी बफ़र की पढ़ाई इस्तेमाल करता है, तो सीमा के बाद का सब कुछ सुरक्षित रखें और अगले उपभोक्ता को सौंपें। अधिकता फेंकना अलग पढ़ाई माप के साथ वही डेटा हानि है।

SOCKS5 को अपना पार्सर चाहिए। उसके प्रतिक्रिया पते की लंबाई पता प्रकार के अनुसार अलग हो सकती है। हर प्रॉक्सी पढ़ाई को निश्चित आठ बाइट की पढ़ाई से बदलना एक प्रोटोकॉल ठीक करेगा और दूसरा तोड़ देगा।

संबंधित लेख