Olvass be nyolc bájtot, majd add át a SOCKS4-alagutat
Kerüld el a cél üdvözlésének elnyelését vagy a nem létező bájtokra való várakozást a SOCKS4-válasz rögzített határának elemzésével.
A SOCKS4 kapcsolatkérés sikeres, de az alkalmazás soha nem látja a kiszolgáló nyitó üdvözlését. Egy hely, ahol érdemes keresni, a csatlakozó első olvasása. A tizenhat bájtos olvasás túl nagy egy nyolcbájtos SOCKS4-válaszhoz.
| Válaszmező | Bájt |
|---|---|
| Válaszverzió-mező | 1 |
| Eredménykód | 1 |
| Portmező | 2 |
| Címmező | 4 |
Az 0x5a eredménykód azt jelzi, hogy a kérést engedélyezték. A SOCKS4a megváltoztatja, hogyan hordozza a kérés a hosztnevet; nem teszik tizenhat bájttá a választ.
A válasz után ugyanaz a TCP-folyam hordozza a cél protokollját. Egy levelezőkiszolgáló azonnal elküldheti az üdvözlését. Ezért egy tizenhat rendelkezésre álló bájtot felemésztő olvasás magával viheti a teljes proxyválaszt és az üdvözlés első nyolc bájtját. Ha még semmi sem következik, egy túlméretezett blokkoló olvasás inkább felesleges várakozást adhat hozzá.
A pontos hossz a parser felelőssége
Egyszer nyolc bájtot kérni nem elégséges bizonyíték arra, hogy nyolc bájt megérkezett. A folyamolvasások kevesebbet adhatnak vissza. Gyűjtsd össze pontosan a válasz hosszát egy határidőn belül, állj le zárt vagy hibás folyamnál, vizsgáld meg a választ, és hagyd a következő bájtokat az alkalmazásnak.
Ha a csatlakozó nagyobb pufferelt olvasást használ, őrizd meg mindent a határ után, és add tovább a következő fogyasztónak. A többlet eldobása ugyanaz az adatvesztés más olvasási mérettel.
A SOCKS5-nek saját parserre van szüksége. A válaszcíme hossza a címtípustól függően eltérő lehet. Ha minden proxyolvasást rögzített nyolcbájtos olvasással helyettesítenénk, az egyik protokollt megjavítanánk, miközben egy másikat elrontanánk.