edge-triggered epoll을 사용하고 epoll에 의해 트리거된 READ 이벤트에서 데이터를 읽기 위해 매번 recv()를 여러 번 호출할 필요가 없는지 이해하려고 합니다...
epoll 매뉴얼 페이지에는 edge-triggered epoll의 경우 bytes_read < bytes_requested인 경우 소켓 읽기를 중지할 수 있다고 명시되어 있습니다. 소켓 버퍼가 분명히 소진되어 epoll_wait로 돌아갈 수 있기 때문입니다.https://man7.org/linux/man-pages/man7/epoll.7.html
스트림 지향 파일(예: 파이프, FIFO, 스트림 소켓)의 경우 읽기/쓰기 I/O 공간 소모는 대상 파일 설명자에서 읽고 쓴 데이터의 양을 확인하여 감지할 수도 있습니다. 예를 들어, 읽을 데이터의 특정 양을 요청하여 read(2)를 호출하고 read(2)가 더 적은 수의 바이트를 반환하는 경우 파일 설명자의 읽기 I/O 공간을 모두 사용했음을 확인할 수 있습니다.
그러나 이것이 소켓 닫기 문제를 어떻게 해결하는지 이해하지 못합니다.
서버가 클라이언트에 128바이트를 보내고 즉시 소켓을 닫는다고 가정합니다. 이제 클라이언트는 epoll_wait에서 속도가 느리고 에지 트리거 EPOLLIN 이벤트에서 데이터 이벤트 및 닫기 이벤트를 수신합니다. 128바이트를 4k 버퍼로 읽는 경우 소켓이 닫혀 있는지 확인하기 위해 read를 다시 호출하지 않으려면 어떻게 해야 합니까? 맨페이지에 따르면 요청한 것보다 적은 바이트를 읽으면 read를 다시 호출할 필요가 없습니다. 그러나 이것이 소켓이 닫힐 가능성을 어떻게 설명합니까?
read를 다시 호출하지 않으면 닫기 이벤트를 놓칠 수도 있습니다. 이제 읽기를 호출해야 할 것 같습니다.적어도ET EPOLLIN 이벤트를 두 번 받을 때마다... 여기에 뭔가 빠진 것 같은 느낌이 듭니다.