피어 측의 소켓이 닫히면 깨진 파이프 오류가 발생한다는 것을 알고 있습니다.
그러나 내 테스트에서 피어 측이 닫힐 때이 측에서 즉각적인 '보내기'호출이 항상 파이프 오류로 이어지지는 않는다는 점에 주목했습니다.
예 :
피어 측에서 소켓을 닫은 후 (close를 호출하여 깨끗한 닫고 피어를 죽여서 비정상적인 닫는 것을 시도했습니다) 40 바이트를 보내려고하면 끊어진 파이프가 나타나지 않지만 시도하면 40000 바이트를 보내면 즉시 깨진 파이프 오류가 발생합니다.
파이프 파손의 원인은 정확히 무엇이며 그 동작을 예측할 수 있습니까?
답변:
네트워크가 닫히는 것을 관찰하는 데 시간이 걸릴 수 있습니다. 전체 시간은 포트로 향하는 패킷이 모두 죽은 것으로 간주되기 전에 닫은 후 명목상 약 2 분 (예, 분!)입니다. 오류 조건은 어느 시점에서 감지됩니다. 작은 쓰기를 사용하면 시스템의 MTU 내부에 있으므로 메시지가 전송 대기열에 추가됩니다. 큰 쓰기를 사용하면 MTU보다 크고 시스템이 문제를 더 빨리 발견합니다. SIGPIPE 신호를 무시하면 함수가 끊어진 파이프에 대해 EPIPE 오류를 반환합니다 (연결의 끊어짐이 감지되는 특정 지점에서).
소켓의 현재 상태는 'keep-alive'활동에 의해 결정됩니다. 귀하의 경우에는 send호출을 발행 할 때 keep-alive활동이 소켓이 활성 상태임을 알려주므로 send호출이 필요한 데이터 (40 바이트)를 버퍼에 쓰고 오류없이 반환 될 수 있습니다.
더 큰 청크를 보낼 때 send 호출은 차단 상태가됩니다.
send man 페이지에서도이를 확인합니다.
메시지가 소켓의 송신 버퍼에 맞지 않으면 소켓이 비 차단 I / O 모드에 있지 않는 한 send ()는 정상적으로 차단됩니다. 비 차단 모드에서는이 경우 EAGAIN을 반환합니다.
따라서 사용 가능한 사용 가능한 버퍼를 차단하는 동안 호출자에게 다른 쪽 끝이 더 이상 존재하지 않는다는 알림 (연결 유지 메커니즘에 의해)이 표시되면 전송 호출이 실패합니다.
언급 된 정보로는 정확한 시나리오를 예측하는 것이 어렵지만 이것이 문제의 원인이라고 생각합니다.