Lees acht bytes en geef dan de SOCKS4-tunnel door
Voorkom dat u de begroeting van de bestemming inslikt of op niet-bestaande bytes wacht door de vaste SOCKS4-antwoordgrens te parsen.
Het SOCKS4-verbindingsverzoek slaagt, maar de toepassing ziet nooit de openingsbegroeting van de server. Een plek om te kijken is de eerste leesactie van de connector. Een leesactie van zestien bytes is te groot voor een SOCKS4-antwoord van acht bytes.
| Antwoordveld | Bytes |
|---|---|
| Veld voor antwoordversie | 1 |
| Resultaatcode | 1 |
| Poortveld | 2 |
| Adresveld | 4 |
De resultaatcode 0x5a geeft aan dat het verzoek is toegekend. SOCKS4a verandert hoe het verzoek een hostnaam draagt; het maakt het antwoord niet zestien bytes.
Na het antwoord draagt dezelfde TCP-stroom het protocol van de bestemming. Een mailserver kan zijn begroeting onmiddellijk sturen. Een leesactie die zestien beschikbare bytes verbruikt, kan daardoor het volledige proxy-antwoord plus de eerste acht bytes van die begroeting meenemen. Als er nog niets volgt, kan een te grote blokkerende leesactie juist een onnodige wachttijd toevoegen.
Exacte lengte is de verantwoordelijkheid van de parser
Eén keer om acht bytes vragen is geen voldoende bewijs dat er acht bytes zijn aangekomen. Stroomleesacties kunnen minder teruggeven. Verzamel precies de lengte van het antwoord binnen een deadline, stop bij een gesloten of mislukte stroom, inspecteer het antwoord en laat de volgende bytes aan de toepassing.
Gebruikt de connector een grotere gebufferde leesactie, bewaar dan alles na de grens en geef het door aan de volgende verbruiker. Het overschot weggooien is hetzelfde gegevensverlies met een andere leesgrootte.
SOCKS5 heeft zijn eigen parser nodig. De lengte van zijn antwoordadres kan per adrestype verschillen. Elke proxy-leesactie vervangen door een vaste leesactie van acht bytes zou het ene protocol repareren en het andere breken.