Leia oito bytes e depois entregue o túnel SOCKS4
Evite engolir a saudação do destino ou esperar por bytes inexistentes analisando o limite fixo da resposta SOCKS4.
O pedido de conexão SOCKS4 é bem-sucedido, mas a aplicação nunca vê a saudação inicial do servidor. Um lugar para olhar é a primeira leitura do conector. Uma leitura de dezesseis bytes é grande demais para uma resposta SOCKS4 de oito bytes.
| Campo da resposta | Bytes |
|---|---|
| Campo de versão da resposta | 1 |
| Código de resultado | 1 |
| Campo de porta | 2 |
| Campo de endereço | 4 |
O código de resultado 0x5a indica que o pedido foi concedido. SOCKS4a muda como o pedido transporta um nome de host; ele não transforma a resposta em dezesseis bytes.
Depois da resposta, o mesmo fluxo TCP transporta o protocolo do destino. Um servidor de correio pode enviar sua saudação imediatamente. Por isso, uma leitura que consome dezesseis bytes disponíveis pode levar a resposta completa do proxy mais os primeiros oito bytes dessa saudação. Se nada seguir ainda, uma leitura bloqueante grande demais pode, em vez disso, acrescentar uma espera desnecessária.
O comprimento exato é responsabilidade do parser
Pedir oito bytes uma única vez não é prova suficiente de que oito bytes chegaram. Leituras de fluxo podem devolver menos. Recolha exatamente o comprimento da resposta dentro de um prazo, pare num fluxo fechado ou falho, inspecione a resposta e deixe os bytes seguintes para a aplicação.
Se o conector usar uma leitura com buffer maior, preserve tudo o que vem depois do limite e passe ao consumidor seguinte. Descartar o excedente é a mesma perda de dados com um tamanho de leitura diferente.
SOCKS5 precisa do seu próprio parser. O endereço da sua resposta pode ter comprimentos diferentes conforme o tipo de endereço. Substituir cada leitura do proxy por uma leitura fixa de oito bytes consertaria um protocolo e quebraria outro.