작성
·
90
0
Session#2 내용까지 보고 질문드립니다.
Send 요청이 동시 다발적으로 발생할 경우 send 순서, 처리가 완료 되기 전 buffer를 건드리는 문제, sendAysnc의 동시다발적 발생으로 인한 부하 문제로 Queue를 사용하여 처리를 한다고 이해를 하였습니다
이런 경우를 Receive 쪽에서도 생각해볼 때 한 클라이언트에서 동시 다발적으로 send를 보낸다면 어쨌든 OnCompleteReceive릉 통해 처리될 것이고 그럼 그 요청만큼 다시 RegisterReceive가 실행이 될 것이라고 생각하고 있습니다.
그렇다면 또 그 요청만큼 recvAysnc가 실행될 것으로 예상되는데 이때는 sendAysnc가 동시 다발적으로 실행되는 것과 같이 생기는 부하 문제, 혹은 야기되는 다른 문제점은 없을까요?
아니면 비동기로 받아주는게 많은 만큼 recv가 쉬워진다던가..
답변 2
0
수신 데이터는 스트림 형식으로 들어오기 때문에 송신자가 송신 함수를 몇 번 호출했는지 알 수 없어요. 송신 함수를 10번 호출해서 보냈는데 수신할 때는 한 번에 받을 수도 있습니다.
TCP에서 데이터를 스트림 형식으로 들어오니까요. 그래서 나중에는 이 데이터 경계를 구분하기 위해 헤더를 사용하게 될 거에요.
0
안녕하세요, 인프런 AI 인턴입니다. 동혁님.
Recv와 Send는 네트워크 통신에서 비동기적으로 운영되기 때문에 각각의 처리가 다르게 수행됩니다. Recv의 경우, 클라이언트에서 데이터를 여러 번 보내는 문제가 있더라도 각 요청이 OnCompleteReceive 이벤트를 통해 처리되며 병목 상황이 덜 발생할 수 있습니다.
Recv의 부하 문제: Send와는 달리 Recv는 데이터를 수신하는 측에서 데이터를 선 처리 후 저장하는 과정이 더 수월합니다. 데이터가 Stream 형태로 받을 수 있기 때문에, 처리하는 애플리케이션 레벨에서 부하를 분산 처리할 수 있습니다. recvAsync 호출이 많아질 경우 그만큼 수신 처리를 병렬적으로 처리할 수 있는 장점도 있습니다.
Buffer 관리: Recv 역시 Send와 마찬가지로 Buffer 관리가 중요합니다. 수신될 데이터의 크기나 횟수가 많아지면 Buffer의 크기와 연산량을 최적화하여 처리해야 하므로, 적절한 크기의 Buffer 할당과 큐/데이터 구조를 잘 설계해야 합니다.
부하 제어: TCP 프로토콜 자체가 정해진 데이터 흐름을 제어하기 때문에, 고정된 패킷 양보다 훨씬 큰 패킷을 한꺼번에 보낸다고 해서 손실되거나 데이터를 놓치는 문제는 TCP 수준에서 방지됩니다.
요약하자면, 네트워크 Recv의 일반적인 부하 문제는 여러 패킷을 한꺼번에 보내는 Send에 비해 상대적으로 관리하기가 용이하며, 구현하는 소프트웨어의 설계에 따라 여전히 관리가 필요합니다. 자세한 구현 방법은 Session #2 강의 듣다가 궁금한점이 있어서 질문드려요
게시글에서도 Rookiss님이 관련된 내용을 설명하고 있습니다. 참고하시길 바랍니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.