Un bucle quere oito bytes dunha resposta SOCKS. Recibiu tres. A seguinte lectura devolve b'', e o bucle engádelle, comproba a lonxitude e volve tentar para sempre.

Iso é un erro de xestión de EOF, non un proxy lento que necesita un tempo de espera máis longo. Nunha recepción normal por un socket de fluxo, unha cadea de bytes baleira significa que o par se desconectou. Os cinco bytes restantes non chegarán por esa conexión.

Un axudante de lectura exacta necesita tres resultados distintos: acumular fragmentos non baleiros, fallar en EOF antes da lonxitude requirida e propagar un tempo de espera ou outro erro de socket. Eses casos non deberían colapsar nun único bucle de reintentos xenérico.

Establece o tempo de espera previsto do socket antes da operación e le as lonxitudes de campo que especifica o protocolo do proxy. Unha soa recepción pode devolver só parte dunha resposta. Á inversa, pedir un búfer fixo grande non fai que todos os enderezos SOCKS teñan esa lonxitude.

Non repares unha dependencia pegando un fragmento antigo de MSG_WAITALL no seu código fonte e supoñendo que cobre EOF, sinais e comportamento da plataforma. Prefire a corrección admitida da implementación mantida, ou implementa deliberadamente o contrato do axudante cando o analizador sexa o teu código.

Conserva cantos bytes se esperaban e se recibiron, sen rexistrar cargas útiles de credenciais. «EOF tras tres de oito bytes de resposta» explica o intercambio roto moito mellor que «o proxy colgouse outra vez».

Artigos relacionados