Læs otte byte, og overlad derefter SOCKS4-tunnelen
Undgå at sluge destinationsserverens hilsen eller vente på byte, der ikke findes, ved at parse den faste SOCKS4-svargrænse.
Anmodningen om SOCKS4-forbindelse lykkes, men programmet ser aldrig serverens indledende hilsen. Et sted at kigge er connector'ens første læsning. En læsning på seksten byte er for stor til et SOCKS4-svar på otte byte.
| Svarfelt | Byte |
|---|---|
| Felt for svarversion | 1 |
| Resultatkode | 1 |
| Portfelt | 2 |
| Adressefelt | 4 |
Resultatkoden 0x5a viser, at anmodningen blev imødekommet. SOCKS4a ændrer, hvordan anmodningen bærer et værtsnavn; det gør ikke svaret til seksten byte.
Efter svaret bærer den samme TCP-strøm destinationens protokol. En mailserver kan sende sin hilsen med det samme. En læsning, der bruger seksten tilgængelige byte, kan derfor tage hele proxy-svaret plus de første otte byte af den hilsen. Hvis der endnu ikke følger noget, kan en for stor blokerende læsning i stedet tilføje en unødvendig ventetid.
Præcis længde er parserens ansvar
At anmode om otte byte én gang er ikke tilstrækkeligt bevis for, at otte byte er ankommet. Strømlæsninger kan returnere mindre. Indsaml præcis svarets længde inden for en tidsfrist, stop ved en lukket eller fejlet strøm, undersøg svaret, og overlad de efterfølgende byte til programmet.
Hvis connector'en bruger en større bufferet læsning, bevar alt efter grænsen og giv det videre til den næste forbruger. At kassere overskuddet er det samme datatab med en anden læsestørrelse.
SOCKS5 har brug for sin egen parser. Længden af dets svaradresse kan variere efter adressetypen. At erstatte hver proxy-læsning med en fast læsning på otte byte ville rette én protokol og ødelægge en anden.