이것은 Linux 커널 2.6 TCP 소켓과 관련이 있습니다.Linux TCP/IP 비 블로킹 소켓 스트림. TCP recv 버퍼는 어떻게됩니까?
대용량의 데이터 (예 : 300MB)를 한 번에 8MB를받는 다른 클라이언트에게 보낼 수 있습니다.
하나의 8MB를 수신 한 후 "수신자"는 오류 처리와 같은 다른 작업을 수행하기 때문에 수신을 중지합니다. 보낸 사람은 EWOULDBLOCK을 얻지 만 비동기 통신이므로 보내기는 다른 쪽 끝의 TCP recv 버퍼를 채 웁니다.
제 질문은 : "보낸 사람"이 EWOULDBLOCK을 받았는데 "수신자"가 수신을 중지하더라도 여전히 TCP recv 버퍼에 데이터가 있습니까? 동일한 소켓이 오류 처리에 사용되므로 "수신기"는 기존 소켓을 재사용하기 전에 TCP recv 버퍼를 지워야합니까?
예. EWOULDBLOCK을 받으면 이미 보낸 일부 데이터가 아직 수신 응용 프로그램에서 읽히지 않았을 가능성이 매우 높습니다. 이 버퍼링 된 데이터는 소켓의 다음 read에서 사용할 수 있습니다.
즉, 수신자가 "Ooops, 더 이상 보내지 않음"메시지를 보낸 사람에게 보냈다면 보낸 사람이 해당 메시지를 처리하고 데이터를 "보내지 않음"을 의미합니다. write()/send()으로 전달되면 현재 진행 중이며 불러올 수 없습니다.
수신자가 더 이상 관심이 없거나 폐기 된 데이터를 읽음으로써 이러한 우발적 인 사건을 처리해야합니다. 따라서 데이터 스트림에 어떤 종류의 거래 구분 기호가 필요할 것입니다.
내 질문은 : "보낸 사람"이 EWOULDBLOCK을 받았는데 "수신자"가 수신을 중지하더라도 데이터가 여전히 TCP recv 버퍼에 있습니까? 보낸 사람이 EWOULDBLOCK을 가지고 있기 때문에 TCP의 데이터가 있습니다
버퍼 을받을 수 있습니다. 그것은 그것이 일어날 수있는 유일한 조건입니다.
질문에 의미가 없습니다.
그러나 TCP recv 버퍼 만 채우고 8MB의 일부만 보내집니다. 그렇다면 폐기 할 금액을 어떻게 알 수 있습니까? – user224579
적어도 당신이하고있는 일을 설명했다면 알 수 없을 것입니다. 소켓은 단지 데이터 스트림입니다. 그들이 가지고있는 유일한 의의는 응용 프로그램 수준 프로토콜, 레코드 등의 측면에서 귀하가 부과하는 것입니다. 이것이 당신이 고려해야 할 조건 인 경우,이를 해결할 수있는 무언가를 정의해야합니다. – Duck
그게 응용 프로그램의 책임입니다. 감사! – user224579