確認問題：書き込み可能なのに接続拒否：非ブロッキング接続

비차단 TCP 연결에서 WRITE 이벤트가 왔다. 성공 판정에 필요한 것은?

• connect_ex를 매번 다시 호출해 시도 횟수를 늘린다
• 쓰기 버퍼 크기가 0보다 크면 성공으로 표시한다
• 연결 중 상태에서 SO_ERROR를 읽어 실제 결과를 보관한다
• 아직 읽은 바이트가 없으면 무조건 실패로 표시한다

오류 기록기가 SO_ERROR를 읽은 뒤 판정기가 다시 읽었다. 무엇이 위험한가?

• 첫 조회가 서버의 listen을 자동으로 중지시킨다
• 두 번째 조회가 연결을 자동으로 다시 시도한다
• 첫 조회의 오류가 모든 프로세스에 영구 복사된다
• 첫 조회가 오류를 지워 두 번째 값이 0일 수 있다

Linux AF_INET 진단기에서 EAGAIN을 AF_UNIX와 동일하게 pending으로 처리해도 되는가?

• 주소 계열별 의미가 다르므로 이 TCP 계약에서는 실패로 분류한다
• 소켓의 모든 주소 계열에서 EAGAIN은 성공을 의미하므로 괜찮다
• 숫자가 같으면 주소 계열과 무관하게 같은 상태 전이를 쓴다
• EAGAIN을 받으면 SO_ERROR를 반복 조회해 반드시 0을 기다린다

소켓을 비차단으로 설정한 뒤 host='localhost'를 받으면 무엇까지 증명되는가?

• 이름 해석과 IPv6 후보 경쟁까지 모두 비차단으로 보장된다
• 소켓 설정만으로 이름 해석의 비차단 동작까지 보장되지는 않는다
• 호스트 이름은 커널이 항상 캐시하므로 별도 단계가 없다
• 연결 전에 발생하는 모든 오류가 SO_ERROR에만 기록된다

Dial이 대기열에 있는 동안 절대 마감에 도달했다. 어떻게 처리하는가?

• 아직 connect하지 않았으므로 마감을 현재 시각에서 다시 시작한다
• 빈 연결은 비용이 없으므로 기한 없이 계속 대기열에 남긴다
• 네트워크 시도를 시작하지 않고 timed_out으로 끝낸다
• 순서 보존을 위해 일단 연결한 뒤 성공이면 마감을 지운다

진단 결과가 connected였다. 이 결과가 직접 뒷받침하는 범위는?

• 원격 API가 요청을 처리하고 DB에 결과를 저장했다
• TLS 인증서의 신뢰성과 호스트 이름 검증이 끝났다
• 이후 모든 송수신이 오류 없이 계속될 것이 보장됐다
• 관찰한 TCP 연결 수립이 성공했으며 업무 정상 여부는 별도다