.NET સોકેટને SOCKS હેન્ડશેકની જરૂર છે

Socket.Connect() ને SOCKS સર્વર તરફ નિર્દેશ કરવાથી તે સર્વર સાથે TCP જોડાણ ખૂલે છે. પછીના બાઇટે હજી SOCKS બોલવું પડે છે. એપ્લિકેશનનું પ્રોટોકોલ તરત જ મોકલવાથી સર્વર બીજી વાતચીતની રાહમાં રહી જાય છે.

SOCKS5 સાથે, જોડાણ સ્થાપિત કરવામાં પદ્ધતિની વાટાઘાટ, પસંદ કરાયેલી પ્રમાણીકરણ આપલે અને ગંતવ્યનું નામ આપતી વિનંતી સમાવેશ થાય છે. ફક્ત સફળ જવાબ જ એપ્લિકેશનના બાઇટ માટે માર્ગ ખોલે છે. આ તબક્કા RFC 1928 માં વ્યાખ્યાયિત છે.

વાટાઘાટને જોડાણ સ્તરમાં રાખો

પોતાના TCP પ્રોટોકોલ ધરાવતી એપ્લિકેશન પ્રોક્સી-જાણકાર કનેક્ટર વાપરી શકે છે જે સ્થાપિત સ્ટ્રીમ પરત કરે છે. પછી બાકીની એપ્લિકેશન તે સ્ટ્રીમ દ્વારા વાંચે અને લખે છે. કનેક્ટરે આંશિક વાંચન, ચલ-લંબાઈના સરનામાં, પ્રમાણીકરણની નિષ્ફળતા અને વાટાઘાટ માટેની સમયમર્યાદા ધ્યાનમાં લેવી પડે.

એક નિશ્ચિત કદનું બફર વાંચીને સફળતા ધારી લેતું હાથે લખેલું અમલીકરણ નાજુક છે. TCP SOCKS સંદેશાઓની સીમાઓ જાળવતું નથી. એપ્લિકેશન પ્રોટોકોલ શરૂ કરતાં પહેલાં તેના સરનામા પ્રકાર દ્વારા વર્ણવાયેલો સંપૂર્ણ જવાબ વાંચો. .NET 7+ માટે CONNECT જવાબ વાંચનાર તે પગલું દર્શાવે છે.

જો સંભાળવાળી લાઇબ્રેરી પહેલેથી આ જોડાણ સ્તર પૂરું પાડે છે, તો તેના સમર્થિત SOCKS આવૃત્તિઓ, પ્રમાણીકરણ પદ્ધતિઓ અને લક્ષ્ય ફ્રેમવર્ક તપાસો. દસ વર્ષ જૂની ફોરમ કડી તપાસ માટેનું પ્રારંભિક સ્થાન છે, વર્તમાન સુસંગતતાનો પુરાવો નહીં.

HTTP ક્લાયન્ટ રૂપરેખાંકનનું અલગ ક્ષેત્ર છે

HTTP ક્લાયન્ટનું પ્રોક્સી સેટિંગ તે HTTP ક્લાયન્ટને ગોઠવે છે. તે પ્રક્રિયામાંના દરેક કાચા સોકેટને બદલતું નથી. Socket API નેટવર્ક એન્ડપોઇન્ટ સ્વીકારે છે અને ઉચ્ચ સ્તરની વાટાઘાટ કૉલરને સોંપે છે.

એન્ક્રિપ્ટેડ એપ્લિકેશન પ્રોટોકોલ માટે, પ્રોક્સી ટનલ સ્થપાયા પછી તેનો TLS હેન્ડશેક કરો. તે તબક્કે ઇચ્છિત ગંતવ્યની ઓળખ ચકાસો. પ્રોક્સી પ્રમાણીકરણ અને ગંતવ્ય પ્રમાણીકરણ અલગ રહે છે, છતાં તે સમાન અંતર્ગત સ્ટ્રીમ વાપરે છે.