Lexo tetë bajt, pastaj dorëzo tunelin SOCKS4
Shmang gëlltitjen e përshëndetjes së destinacionit ose pritjen për bajt që nuk ekzistojnë duke analizuar kufirin fiks të përgjigjes SOCKS4.
Kërkesa për lidhjen SOCKS4 përfundon me sukses, por aplikacioni nuk e sheh kurrë përshëndetjen hapëse të serverit. Një vend për të parë është leximi i parë i lidhësit. Një lexim prej gjashtëmbëdhjetë bajtësh është shumë i madh për një përgjigje SOCKS4 prej tetë bajtësh.
| Fusha e përgjigjes | Bajt |
|---|---|
| Fusha e versionit të përgjigjes | 1 |
| Kodi i rezultatit | 1 |
| Fusha e portës | 2 |
| Fusha e adresës | 4 |
Kodi i rezultatit 0x5a tregon se kërkesa u miratua. SOCKS4a ndryshon mënyrën se si kërkesa mbart një emër hosti; nuk e kthen përgjigjen në gjashtëmbëdhjetë bajt.
Pas përgjigjes, i njëjti rrjedhë TCP mbart protokollin e destinacionit. Një server poste mund të dërgojë përshëndetjen e tij menjëherë. Prandaj një lexim që konsumon gjashtëmbëdhjetë bajt të disponueshëm mund të marrë përgjigjen e plotë të proxy-t plus tetë bajtët e parë të asaj përshëndetjeje. Nëse ende nuk vjen asgjë, një lexim bllokues tepër i madh mund të shtojë në vend të kësaj një pritje të panevojshme.
Gjatësia e saktë është përgjegjësi e analizuesit
Kërkimi i tetë bajtëve një herë nuk është provë e mjaftueshme që kanë mbërritur tetë bajt. Leximet e rrjedhës mund të kthejnë më pak. Mblidh saktësisht gjatësinë e përgjigjes brenda një afati, ndalo në një rrjedhë të mbyllur ose të dështuar, inspekto përgjigjen dhe lëri bajtët pasues për aplikacionin.
Nëse lidhësi përdor një lexim me bufer më të madh, ruaj gjithçka pas kufirit dhe kaloja konsumatorit të radhës. Hedhja e tepricës është e njëjta humbje e të dhënave me një madhësi tjetër leximi.
SOCKS5 kërkon analizuesin e vet. Gjatësia e adresës së përgjigjes së tij mund të ndryshojë sipas llojit të adresës. Zëvendësimi i çdo leximi të proxy-t me një lexim fiks prej tetë bajtësh do të rregullonte një protokoll duke prishur një tjetër.