RecvBuffer 질문

안녕하세요.

Session에서 _recvArgs.SetBuffer() 하는 부분에서 궁금증이 생겼습니다.

_recvBuffer.WriteSegment는 다음에 올 패킷 사이즈가 어느 정도인지 모르니

버퍼의 offset + writePos부터 여유공간 끝까지(FreeSize)를 뭉탱이로 가리켜서 주는걸로 이해했습니다.

그리고 _recvArgs는 WriteSegment가 가리키는 공간을 자신의 버퍼로 사용합니다.

만약, 실제로 보내고자 했던 패킷의 사이즈가 10인데, _recvArgs의 FreeSize가 5라면,

소켓은 일단 5만큼만 버퍼에 넣은 다음에 버리고, 나머지 5만큼의 재전송을 요청하는 건가요?

아니면 아예 버리고 재전송을 요청하는건가요?

그것도 아니라면 물밑(하위 레이어)에서 버퍼가 꽉 찼다는 신호를 서로 주고받아서 혼잡(?)이라 판단하고 애초에 보내지 않고 기다리는건가요? (버퍼가 비어지길 기다리다가 지치면 Disconnect 혹은 Loss?)

그리고 RecvBuffer의 Buffer가

TCP 이론을 배울 때 말하는 window size와 직접적으로 연관되는 건가요?

아니면 소켓 별도의 버퍼가 또 따로 있는건가요?

안녕하세요, 인프런 AI 인턴입니다.

김병대님, 질문하신 내용은 네트워크 프로그래밍, 특히 TCP/IP 프로토콜에 대한 소켓 버퍼링 처리와 관련되어 있는 것으로 보입니다. 질문하신 내용은 커널 버퍼와 사용자 레벨의 버퍼, 그리고 TCP 소켓 통신에서의 흐름 제어(window size)와 관련이 깊습니다.

TCP 소켓 통신에서 송신자는 정해진 윈도우 크기만큼의 데이터를 전송하며, 수신자는 해당 데이터를 처리하고 다시 ACK를 보내 윈도우 크기를 갱신합니다. 이 과정에서 수신자의 recvArgs가 가리키는 버퍼의 여유 공간이 송신 데이터 크기보다 작을 경우, TCP 스택은 자동으로 데이터를 분할하여 수신합니다. 즉, 수신 가능한 크기만큼 먼저 받고, 나머지 데이터는 다음 수신에서 처리됩니다. 데이터가 버려지거나 재전송되는 것이 아닙니다. 혼잡 상황에서는 TCP의 혼잡 제어 메커니즘이 작동하여 데이터 전송 속도를 조절합니다.

사용자 레벨의 RecvBuffer와 소켓의 커널 레벨 버퍼는 다릅니다. RecvBuffer는 애플리케이션에서 관리하는 버퍼이며, 커널 레벨의 소켓 버퍼는 운영 체제가 관리합니다. TCP 윈도우 크기는 이 커널 레벨의 버퍼 크기에 영향을 받습니다.

위 질문과 관련하여 찾을 수 있는 가장 유사한 질문은 다음과 같습니다:

RecvBuffer와 SendBuffer 클래스 관련 질문드립니다.
- 이 질문에서는 RecvBuffer의 복사과정과 버퍼 처리에 대한 설명이 포함되어 있으며, 김병대님의 질문에 대한 일부 해답을 제공할 수 있습니다.
Buffer와 Packet에 관한 의문
- TCP 특성과 데이터 전송 과정에서의 버퍼링 처리에 대한 궁금증에 관한 질문이며, 이 또한 김병대님의 질문과 관련된 통찰을 제공합니다.

이정도로 직접적인 답변을 제공하기는 어렵지만 이와 관련된 원론적 설명을 들어볼 수 있는 자료입니다. 다만, 질문자님이 직접적인 코드 레벨에서의 동작을 문의하시는 것으로 판단됩니다. 보다 정확한 답변을 원하신다면 이어서 구체적인 코딩과 관련된 질문을 해주시면 좋을 것 같습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변