SOCKS4 કનેક્શન વિનંતી સફળ થાય છે, પણ એપ્લિકેશન સર્વરનું શરૂઆતનું અભિવાદન ક્યારેય જોતી નથી. જોવાનું એક સ્થાન કનેક્ટરનું પ્રથમ વાંચન છે. સોળ બાઇટનું વાંચન આઠ બાઇટના SOCKS4 પ્રતિસાદ માટે બહુ મોટું છે.

પ્રતિસાદ ક્ષેત્રબાઇટ
પ્રતિસાદ આવૃત્તિ ક્ષેત્ર1
પરિણામ કોડ1
પોર્ટ ક્ષેત્ર2
સરનામું ક્ષેત્ર4

પરિણામ કોડ 0x5a દર્શાવે છે કે વિનંતી મંજૂર થઈ છે. SOCKS4a બદલે છે કે વિનંતી હોસ્ટનામ કેવી રીતે વહન કરે છે; તે પ્રતિસાદને સોળ બાઇટમાં ફેરવતું નથી.

પ્રતિસાદ પછી એ જ TCP પ્રવાહ ગંતવ્યનું પ્રોટોકોલ વહન કરે છે. મેઇલ સર્વર તરત જ તેનું અભિવાદન મોકલી શકે છે. તેથી સોળ ઉપલબ્ધ બાઇટ વાપરતું વાંચન સંપૂર્ણ પ્રોક્સી પ્રતિસાદ ઉપરાંત તે અભિવાદનના પ્રથમ આઠ બાઇટ લઈ શકે છે. જો હજી કંઈ ન આવે, તો વધુ પડતું બ્લોકિંગ વાંચન તેના બદલે બિનજરૂરી રાહ ઉમેરી શકે છે.

ચોક્કસ લંબાઈ પાર્સરની જવાબદારી છે

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

જો કનેક્ટર મોટું બફર કરેલું વાંચન વાપરે, તો સીમા પછીનું બધું સાચવો અને આગલા વપરાશકર્તાને આપો. વધારાનું ફેંકવું એ જ માહિતીની ખોટ છે, ફક્ત વાંચનનું માપ અલગ છે.

SOCKS5ને તેનું પોતાનું પાર્સર જોઈએ. તેના પ્રતિસાદ સરનામાની લંબાઈ સરનામાના પ્રકાર પ્રમાણે અલગ હોઈ શકે છે. દરેક પ્રોક્સી વાંચનને નિશ્ચિત આઠ બાઇટના વાંચનથી બદલવાથી એક પ્રોટોકોલ સુધરે છે અને બીજો તૂટે છે.

સંબંધિત લેખો