Nagtatagumpay ang kahilingan sa koneksyon ng SOCKS4, ngunit hindi kailanman nakikita ng aplikasyon ang pambungad na pagbati ng server. Isang lugar na dapat tingnan ay ang unang pagbasa ng konektor. Ang pagbasa ng labing-anim na byte ay masyadong malaki para sa walong byte na tugon ng SOCKS4.

Patlang ng tugonByte
Patlang ng bersyon ng tugon1
Kodigo ng resulta1
Patlang ng port2
Patlang ng address4

Ipinapahiwatig ng kodigo ng resulta 0x5a na naipagkaloob ang kahilingan. Binabago ng SOCKS4a kung paano dinadala ng kahilingan ang pangalan ng host; hindi nito ginagawang labing-anim na byte ang tugon.

Pagkatapos ng tugon, dinadala ng parehong TCP stream ang protocol ng destinasyon. Maaaring magpadala agad ng pagbati ang isang mail server. Kaya ang pagbasang gumagamit ng labing-anim na available na byte ay maaaring kumuha ng buong tugon ng proxy at ang unang walong byte ng pagbatings iyon. Kung wala pang sumusunod, ang sobrang laking blocking read ay maaaring magdagdag ng hindi kailangang paghihintay.

Ang eksaktong haba ay responsibilidad ng parser

Ang paghingi ng walong byte nang isang beses ay hindi sapat na patunay na dumating ang walong byte. Maaaring kakaunti ang ibalik ng mga pagbasa sa stream. Kolektahin nang eksakto ang haba ng tugon sa loob ng takdang panahon, huminto sa sarado o bigong stream, siyasatin ang tugon, at iwanan ang mga susunod na byte para sa aplikasyon.

Kung gumagamit ang konektor ng mas malaking buffered read, panatilihin ang lahat pagkatapos ng hangganan at ipasa ito sa susunod na konsyumer. Ang itapon ang sobra ay parehong pagkawala ng datos na may ibang laki ng pagbasa.

Kailangan ng SOCKS5 ang sarili nitong parser. Maaaring magkaiba ang haba ng address ng tugon nito ayon sa uri ng address. Ang palitan ang bawat pagbasa ng proxy ng nakapirming walong byte na pagbasa ay aayusin ang isang protocol habang sinisira ang isa pa.

Kaugnay na mga artikulo