Le oito bytes e despois cede o túnel SOCKS4
Evita tragarte o saúdo do destino ou esperar bytes inexistentes analizando a fronteira fixa da resposta SOCKS4.
A solicitude de conexión SOCKS4 remata ben, pero a aplicación nunca ve o saúdo inicial do servidor. Un lugar onde mirar é a primeira lectura do conector. Unha lectura de dezaseis bytes é demasiado grande para unha resposta SOCKS4 de oito bytes.
| Campo da resposta | Bytes |
|---|---|
| Campo de versión da resposta | 1 |
| Código de resultado | 1 |
| Campo de porto | 2 |
| Campo de enderezo | 4 |
O código de resultado 0x5a indica que a solicitude foi concedida. SOCKS4a cambia como a solicitude transporta un nome de host; non converte a resposta en dezaseis bytes.
Tras a resposta, o mesmo fluxo TCP transporta o protocolo do destino. Un servidor de correo pode enviar o seu saúdo de inmediato. Por iso, unha lectura que consome dezaseis bytes dispoñibles pode levar a resposta completa do proxy máis os primeiros oito bytes dese saúdo. Se aínda non segue nada, unha lectura bloqueante demasiado grande pode engadir unha espera innecesaria.
A lonxitude exacta é responsabilidade do analizador
Pedir oito bytes unha soa vez non é proba suficiente de que chegasen oito bytes. As lecturas de fluxo poden devolver menos. Recolle exactamente a lonxitude da resposta dentro dun prazo, detente nun fluxo pechado ou fallido, inspecciona a resposta e deixa os bytes seguintes para a aplicación.
Se o conector usa unha lectura con búfer maior, conserva todo o que veña despois da fronteira e pásao ao seguinte consumidor. Descartar o sobrante é a mesma perda de datos cun tamaño de lectura distinto.
SOCKS5 necesita o seu propio analizador. O enderezo da súa resposta pode ter lonxitudes distintas segundo o tipo de enderezo. Substituír cada lectura do proxy por unha lectura fixa de oito bytes arranxaría un protocolo á vez que rompería outro.