• 카테고리

    질문 & 답변
  • 세부 분야

    게임 프로그래밍

  • 해결 여부

    미해결

send 와 recv 관련하여 질문이 있습니다!

24.03.24 00:46 작성 조회수 77

1

클라입장에서 Connect를 통해 연결을하고 연결된 소켓에 Send를 하게되면 서버입장에서 Recv하게되는부분에서

1.

public void Start(Socket socket)

{

_socket = socket;

_recvArgs.Completed += new EventHandler<SocketAsyncEventArgs>(OnRecvCompleted);

_recvArgs.SetBuffer(new byte[1024], 0, 1024);

_sendArgs.Completed += new EventHandler<SocketAsyncEventArgs>(OnSendCompleted);

RegisterRecv();

}

이부분에서 RegisterRecv를 하나만 써 준 것이 낚싯대에 비유하여 접근을 하고있을시 다른쪽에서 접근을 못한다고 하셨는데. 이게 구조적으로 그렇게 짜여진 것인가요??

+ 또 RegisterRecv() 이것을 여러게 써주면 lock을 걸어야 하는건가요 ??

 

2.

그리고 OnSendCompleted 에도 lock을 건 이유가

_sendArgs.Completed += new EventHandler<SocketAsyncEventArgs>(OnSendCompleted);

이 부분에서 중복해서 들어오는 것을 방지하기 위해 거셨다고 하셨습니다. 그럼 Recv의

_recvArgs.Completed += new EventHandler<SocketAsyncEventArgs>(OnRecvCompleted);

이 부분은 어떻게 다른건가요??

 

  1. 이 부분은 제 나름대로 이해하려고 예를 든 부분입니다. 제대로 이해했는지 봐주시면 감사합니다!

Send와 Recv를 게임의 1:1 채팅에 적용하면 A유저와 B 유저가 1:1 채팅을 하고있는 중에 A유저가 채팅을 보내면 클라에서 Send를 하고 서버에서 Recv를 해 받고 그걸 서버 Send를 통해 B유저 클라에 보내준다 (이 부분에서 서버 Send는 1:1하고있는 B에만 가야하니까 lock을 검 : 또 다른 유저(클라)가 보낸 채팅? 들이 섞이지않게... )

 

 

 

 

답변 2

·

답변을 작성해보세요.

1

중요한 포인트이지만, 고민을 더 하셔야 합니다.
Part4 유니티 실습 or Part7을 다 보고 다시 질문을 해주세요.

살짝 힌트만 드리자면..
1. 동일 세션 대상으로, RegisterRecv를 여러 개를 걸 이유는 없습니다.
2. Recv는 기존 것을 받았으면 다음 것을 받는게 합리적이고, Send는 그렇지 않고 상황에 따라 중첩해서 일어날 수 있습니다.
3. 거의 비슷하긴 한데 lock 을 걸어야 하는 사유가 잘못되었습니다.

pnj991122님의 프로필

pnj991122

질문자

2024.03.25

감사합니다! 강의를 계속 들으면서 고민을 해 보겠습니다!

0

인프런 AI 인턴님의 프로필

인프런 AI 인턴

2024.03.24

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

질문자님께서 질문하신 내용에 관하여 살펴봤을 때, 유사한 상황을 다룬 기존의 질문과 답변이 있어 링크와 함께 간략한 설명을 제공해드리고자 합니다.

  1. RegisterRecv가 여러 번 호출될 경우와 관련된 질문: 질문자님께서는 RegisterRecv() 호출 방식과 관련해, 여러 번 호출되는 경우 lock 처리의 필요성에 대해 문의하셨습니다. 이와 관련하여, Send는 Lock이 있고 Recv에는 Lock이 없는 이유가 무엇인가요?에서 Recv의 경우는 명시적으로 여러 번 호출될 상황이 아니고, 딱 1번에 1개의 쓰레드만 접근할 수 있기 때문에 lock 처리가 필요 없다는 설명이 있습니다. Send의 경우는 어느 시점에든 호출할 수 있기 때문에 lock이 필요하다고 합니다.

  2. OnSendCompleted와 OnRecvCompleted의 차이점: OnSendCompleted에서 lock을 건 이유는 동시다발적으로 Send 호출이 이루어질 경우를 방지하기 위함인 반면, Recv에 대해서는 리시브 비동기에 관련하여 궁금한 것이 있습니다.에서 별도의 쓰레드에서 실행될 수 있으며, 클라이언트에서 보낸 패킷 처리와 관련된 비동기 호출 처리를 다루고 있습니다. 이 것은 Recv가 내부적으로 쓰레드를 관리하는 방식이 다르기 때문입니다.

이러한 설명을 바탕으로, RegisterRecv의 경우 한 번의 작업 처리를 위해 설계된 것이며, 그러므로 여러 번 호출될 상황이 아니라는 것을 알 수 있습니다. 또, SendRecv의 동작 방식이 구조적으로 서로 다르게 설계되었기 때문에, 각각에 대해 lock 처리와 이벤트 핸들링에서 차이가 있는 것입니다.

이 측면에서 질문자님의 이해는 기본적으로 정확하다고 볼 수 있습니다. 그러나 각 메서드와 이벤트 처리의 내부 로직에 대한 더 깊은 이해가 필요할 수 있으며, 상황에 따라 개발 환경과 요구 사항에 맞게 적절한 구현 방법을 선택해야 합니다.

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