Leer ocho bytes y luego ceder el túnel SOCKS4
Evita tragarte el saludo del destino o esperar bytes inexistentes analizando el límite fijo de la respuesta SOCKS4.
La solicitud de conexión SOCKS4 se completa, pero la aplicación nunca ve el saludo inicial del servidor. Un lugar donde mirar es la primera lectura del conector. Una lectura de dieciséis bytes es demasiado grande para una respuesta SOCKS4 de ocho bytes.
| Campo de la respuesta | Bytes |
|---|---|
| Campo de versión de la respuesta | 1 |
| Código de resultado | 1 |
| Campo de puerto | 2 |
| Campo de dirección | 4 |
El código de resultado 0x5a indica que la solicitud fue concedida. SOCKS4a cambia cómo la solicitud transporta un nombre de host; no convierte la respuesta en dieciséis bytes.
Tras la respuesta, el mismo flujo TCP transporta el protocolo del destino. Un servidor de correo puede enviar su saludo de inmediato. Por eso, una lectura que consume dieciséis bytes disponibles puede llevarse la respuesta completa del proxy más los primeros ocho bytes de ese saludo. Si todavía no sigue nada, una lectura bloqueante demasiado grande puede en cambio añadir una espera innecesaria.
La longitud exacta es responsabilidad del analizador
Pedir ocho bytes una sola vez no es prueba suficiente de que hayan llegado ocho bytes. Las lecturas de flujo pueden devolver menos. Reúne exactamente la longitud de la respuesta dentro de un plazo, detente ante un flujo cerrado o fallido, inspecciona la respuesta y deja los bytes siguientes para la aplicación.
Si el conector usa una lectura con búfer más grande, conserva todo lo que haya después del límite y pásalo al siguiente consumidor. Descartar el sobrante es la misma pérdida de datos con otro tamaño de lectura.
SOCKS5 necesita su propio analizador. La dirección de su respuesta puede tener longitudes distintas según el tipo de dirección. Sustituir cada lectura del proxy por una lectura fija de ocho bytes arreglaría un protocolo a la vez que rompería otro.