Les åtte byte og overlat deretter SOCKS4-tunnelen
Unngå å svelge hilsenen fra destinasjonen eller vente på byte som ikke finnes, ved å analysere den faste SOCKS4-svargrensen.
SOCKS4-tilkoblingsforespørselen lykkes, men applikasjonen ser aldri serverens åpningshilsen. Et sted å se er koblerens første lesing. En lesing på seksten byte er for stor for et SOCKS4-svar på åtte byte.
| Svarfelt | Byte |
|---|---|
| Felt for svarversjon | 1 |
| Resultatkode | 1 |
| Portfelt | 2 |
| Adressefelt | 4 |
Resultatkoden 0x5a viser at forespørselen ble innvilget. SOCKS4a endrer hvordan forespørselen bærer et vertsnavn; det gjør ikke svaret til seksten byte.
Etter svaret bærer den samme TCP-strømmen destinasjonens protokoll. En e-postserver kan sende hilsenen sin umiddelbart. En lesing som bruker seksten tilgjengelige byte, kan derfor ta hele proxy-svaret pluss de første åtte bytene av den hilsenen. Hvis ingenting følger ennå, kan en altfor stor blokkerende lesing i stedet legge til en unødvendig ventetid.
Nøyaktig lengde er analysatorens ansvar
Å be om åtte byte én gang er ikke tilstrekkelig bevis for at åtte byte har ankommet. Strømlesinger kan returnere mindre. Samle nøyaktig svarets lengde innen en frist, stopp ved en lukket eller mislykket strøm, undersøk svaret, og la de neste bytene være igjen til applikasjonen.
Hvis kobleren bruker en større bufret lesing, bevar alt etter grensen og send det videre til neste forbruker. Å kaste overskuddet er det samme datatapet med en annen lesestørrelse.
SOCKS5 trenger sin egen analysator. Lengden på svaradressen kan variere etter adressetypen. Å erstatte hver proxy-lesing med en fast lesing på åtte byte ville rette én protokoll og ødelegge en annen.