Irakurri zortzi byte eta gero eman SOCKS4 tunela
Saihestu helmugaren agurra irestea edo existitzen ez diren byteen zain egotea SOCKS4 erantzunaren muga finkoa analizatuz.
SOCKS4 konexio-eskaera ondo egiten da, baina aplikazioak ez du inoiz zerbitzariaren hasierako agurra ikusten. Begiratzeko leku bat konektorearen lehen irakurketa da. Hamasei byteko irakurketa handiegia da zortzi byteko SOCKS4 erantzun baterako.
| Erantzun eremua | Byteak |
|---|---|
| Erantzunaren bertsio eremua | 1 |
| Emaitza kodea | 1 |
| Portu eremua | 2 |
| Helbide eremua | 4 |
Emaitza kodeak 0x5a eskaera onartu zela adierazten du. SOCKS4a-k aldatzen du eskaerak ostalari-izena nola daraman; ez du erantzuna hamasei byte bihurtzen.
Erantzunaren ondoren, TCP korronte berak helmugako protokoloa darama. Posta-zerbitzari batek bere agurra berehala bidal dezake. Beraz, hamasei byte erabilgarri kontsumitzen dituen irakurketa batek proxyaren erantzun osoa eta agur horren lehen zortzi byteak har ditzake. Oraindik ezer ez badoa, blokeatzen duen irakurketa handiegi batek alferrikako itxaronaldia gehi dezake.
Luzera zehatza analizatzailearen erantzukizuna da
Behin zortzi byte eskatzea ez da nahikoa zortzi byte iritsi direla frogatzeko. Korronte-irakurketek gutxiago itzul dezakete. Bildu erantzunaren luzera zehatza epe baten barruan, gelditu itxita edo huts egindako korrontean, aztertu erantzuna eta utzi hurrengo byteak aplikazioari.
Konektoreak irakurketa buffer handiagoa erabiltzen badu, gorde muga ondorengo guztia eta eman hurrengo kontsumitzaileari. Soberakina botatzea datu-galera bera da irakurketa-tamaina ezberdinarekin.
SOCKS5ek bere analizatzailea behar du. Bere erantzun-helbideak luzera desberdinak izan ditzake helbide motaren arabera. Proxy irakurketa bakoitza zortzi byteko irakurketa finko batekin ordezkatzeak protokolo bat konponduko luke bestea hautsi bitartean.