Leggi otto byte, poi cedi il tunnel SOCKS4
Evita di inghiottire il saluto della destinazione o di attendere byte inesistenti analizzando il confine fisso della risposta SOCKS4.
La richiesta di connessione SOCKS4 riesce, ma l'applicazione non vede mai il saluto iniziale del server. Un punto da controllare è la prima lettura del connettore. Una lettura di sedici byte è troppo grande per una risposta SOCKS4 di otto byte.
| Campo della risposta | Byte |
|---|---|
| Campo versione della risposta | 1 |
| Codice di risultato | 1 |
| Campo porta | 2 |
| Campo indirizzo | 4 |
Il codice di risultato 0x5a indica che la richiesta è stata concessa. SOCKS4a cambia il modo in cui la richiesta trasporta un nome host; non trasforma la risposta in sedici byte.
Dopo la risposta, lo stesso flusso TCP trasporta il protocollo di destinazione. Un server di posta può inviare subito il proprio saluto. Una lettura che consuma sedici byte disponibili può quindi prendere la risposta completa del proxy più i primi otto byte di quel saluto. Se non segue ancora nulla, una lettura bloccante troppo grande può invece aggiungere un'attesa inutile.
La lunghezza esatta è responsabilità del parser
Chiedere otto byte una volta non è prova sufficiente che siano arrivati otto byte. Le letture di flusso possono restituirne meno. Raccogli esattamente la lunghezza della risposta entro una scadenza, fermati su un flusso chiuso o fallito, ispeziona la risposta e lascia i byte successivi all'applicazione.
Se il connettore usa una lettura bufferizzata più grande, conserva tutto ciò che segue il confine e passalo al consumatore successivo. Scartare l'eccedenza è la stessa perdita di dati con una dimensione di lettura diversa.
SOCKS5 richiede un proprio parser. L'indirizzo della sua risposta può avere lunghezze diverse a seconda del tipo di indirizzo. Sostituire ogni lettura del proxy con una lettura fissa di otto byte riparerebbe un protocollo rompendone un altro.