आठ बाइट वाचा, मग SOCKS4 बोगदा सुपूर्द करा
SOCKS4 प्रतिसादाची निश्चित सीमा विश्लेषित करून गंतव्याचे अभिवादन गिळणे किंवा नसलेल्या बाइटची वाट पाहणे टाळा.
SOCKS4 कनेक्शन विनंती यशस्वी होते, पण अनुप्रयोगाला सर्व्हरचे सुरुवातीचे अभिवादन कधीच दिसत नाही. पाहण्याची एक जागा कनेक्टरचे पहिले वाचन आहे. सोळा बाइटचे वाचन आठ बाइटच्या SOCKS4 प्रतिसादासाठी खूप मोठे आहे.
| प्रतिसाद क्षेत्र | बाइट |
|---|---|
| प्रतिसाद आवृत्ती क्षेत्र | 1 |
| निकाल कोड | 1 |
| पोर्ट क्षेत्र | 2 |
| पत्ता क्षेत्र | 4 |
निकाल कोड 0x5a विनंती मंजूर झाली हे दर्शवतो. SOCKS4a विनंती होस्टनाव कसे वाहते ते बदलते; ते प्रतिसादाला सोळा बाइट करत नाही.
प्रतिसादानंतर तोच TCP प्रवाह गंतव्याचे प्रोटोकॉल वाहतो. मेल सर्व्हर आपले अभिवादन लगेच पाठवू शकतो. म्हणून सोळा उपलब्ध बाइट वापरणारे वाचन संपूर्ण प्रॉक्सी प्रतिसादासह त्या अभिवादनाचे पहिले आठ बाइट घेऊ शकते. अजून काही न आल्यास, खूप मोठे ब्लॉकिंग वाचन त्याऐवजी अनावश्यक प्रतीक्षा जोडू शकते.
अचूक लांबी पार्सरची जबाबदारी आहे
एकदा आठ बाइट मागणे हा आठ बाइट आले याचा पुरेसा पुरावा नाही. प्रवाह वाचने कमी परत देऊ शकतात. मुदतीत प्रतिसादाची लांबी अचूक गोळा करा, बंद किंवा अयशस्वी प्रवाहावर थांबा, प्रतिसाद तपासा आणि पुढील बाइट अनुप्रयोगासाठी ठेवा.
कनेक्टर मोठे बफर वाचन वापरत असल्यास सीमेनंतरचे सर्व जपून ठेवा आणि पुढील ग्राहकाकडे द्या. अधिक भाग टाकून देणे हेच वेगळ्या वाचन आकारासह तेच डेटा नुकसान आहे.
SOCKS5 ला स्वतःचा पार्सर लागतो. त्याच्या प्रतिसाद पत्त्याची लांबी पत्ता प्रकारानुसार वेगळी असू शकते. प्रत्येक प्रॉक्सी वाचन निश्चित आठ बाइटच्या वाचनाने बदलल्यास एक प्रोटोकॉल सुधारेल आणि दुसरा तुटेल.