Python SOCKS 읽기 루프에서 EOF 처리하기

한 루프가 SOCKS 응답의 여덟 바이트를 원합니다. 세 바이트를 받았습니다. 다음 읽기는 b''을 반환하고, 루프는 그것을 덧붙이고 길이를 확인한 뒤 영원히 다시 시도합니다.

이것은 EOF 처리 버그이지 더 긴 타임아웃이 필요한 느린 프록시가 아닙니다. 일반 스트림 소켓 수신에서 빈 바이트 문자열은 상대방이 연결을 끊었다는 뜻입니다. 남은 다섯 바이트는 그 연결로 오지 않습니다.

정확 읽기 헬퍼에는 세 가지 별개의 결과가 필요합니다. 비어 있지 않은 청크를 누적하고, 필요한 길이에 도달하기 전에 EOF에서 실패하며, 타임아웃이나 다른 소켓 오류를 전파해야 합니다. 그런 경우들을 하나의 일반 재시도 루프로 합쳐서는 안 됩니다.

작업 전에 소켓의 의도된 타임아웃을 설정하고 프록시 프로토콜이 지정하는 필드 길이를 읽으십시오. 단일 수신은 응답의 일부만 반환할 수 있습니다. 반대로 큰 고정 버퍼를 요청한다고 해서 모든 SOCKS 주소가 그 길이가 되는 것은 아닙니다.

오래된 MSG_WAITALL 스니펫을 의존성 소스에 붙여 넣고 EOF, 시그널, 플랫폼 동작을 다룬다고 가정하여 고치지 마십시오. 유지 관리되는 구현의 지원되는 수정을 선호하거나, 파서가 직접 작성한 코드라면 헬퍼의 계약을 의도적으로 구현하십시오.

자격 증명 페이로드를 기록하지 않고 예상된 바이트 수와 수신된 바이트 수를 보존하십시오. “여덟 응답 바이트 중 세 바이트 후 EOF”는 “프록시가 또 멈췄다”보다 깨진 교환을 훨씬 잘 설명합니다.