.NET सॉकेट को SOCKS हैंडशेक चाहिए

Socket.Connect() को SOCKS सर्वर की ओर इंगित करने से उस सर्वर तक TCP कनेक्शन खुलता है। अगले बाइट्स को अब भी SOCKS बोलना होता है। एप्लिकेशन का प्रोटोकॉल तुरंत भेजने से सर्वर किसी दूसरी बातचीत का इंतज़ार करता रह जाता है।

SOCKS5 में, कनेक्शन स्थापित करने में विधि पर बातचीत, चुना गया कोई भी प्रमाणीकरण आदान-प्रदान, और गंतव्य का नाम लेने वाला अनुरोध शामिल होता है। केवल सफल उत्तर ही एप्लिकेशन के बाइट्स के लिए रास्ता खोलता है। ये चरण RFC 1928 में परिभाषित हैं।

बातचीत को कनेक्शन परत में रखें

अपने TCP प्रोटोकॉल वाला एप्लिकेशन प्रॉक्सी-जागरूक कनेक्टर इस्तेमाल कर सकता है जो स्थापित स्ट्रीम लौटाता है। फिर बाकी एप्लिकेशन उसी स्ट्रीम से पढ़ता और लिखता है। कनेक्टर को आंशिक पठन, बदलती लंबाई के पते, प्रमाणीकरण विफलताएँ और बातचीत के लिए एक समय-सीमा ध्यान में रखनी होती है।

हाथ से लिखा गया ऐसा कार्यान्वयन जो एक निश्चित आकार का बफ़र पढ़ता है और सफलता मान लेता है, नाज़ुक होता है। TCP SOCKS संदेशों की सीमाएँ सुरक्षित नहीं रखता। एप्लिकेशन प्रोटोकॉल शुरू करने से पहले उसके पता प्रकार द्वारा बताया गया पूरा उत्तर पढ़ें। .NET 7+ के लिए CONNECT उत्तर पाठक उस चरण को दर्शाता है।

अगर कोई अनुरक्षित लाइब्रेरी पहले से यह कनेक्शन परत देती है, तो उसके समर्थित SOCKS संस्करण, प्रमाणीकरण विधियाँ और लक्ष्य फ़्रेमवर्क जाँचें। दस साल पुराना फ़ोरम लिंक जाँच का शुरुआती बिंदु है, वर्तमान अनुकूलता का प्रमाण नहीं।

HTTP क्लाइंट कॉन्फ़िगरेशन का दायरा अलग है

HTTP क्लाइंट की प्रॉक्सी सेटिंग उसी HTTP क्लाइंट को कॉन्फ़िगर करती है। यह प्रक्रिया के हर कच्चे सॉकेट को नहीं बदलती। Socket API एक नेटवर्क एंडपॉइंट स्वीकार करता है और उच्च स्तरीय बातचीत कॉलर पर छोड़ देता है।

एन्क्रिप्टेड एप्लिकेशन प्रोटोकॉल के लिए, प्रॉक्सी टनल स्थापित होने के बाद उसका TLS हैंडशेक करें। उसी चरण में इच्छित गंतव्य की पहचान सत्यापित करें। प्रॉक्सी प्रमाणीकरण और गंतव्य प्रमाणीकरण अलग रहते हैं, भले ही वे एक ही अंतर्निहित स्ट्रीम इस्तेमाल करते हों।