Packet을 처리하는 NetworkManager의 동작과 GameWorld를 업데이트하는 동작을 서로 다른 스레드로 분리하는 게 효율이 좋을 것 같다. 그래서 패킷을 처리하는 queue를 만들어 이를 두 class 간 공유하는 것으로 설계하고자 한다.
Packet Queue를 만들면 될 것 같은데, 내가 주저하는 이유. Packet Queue의 코드가 운용되고 있는 모양을 직접 본 적이 없다. 그래서 이게 정말 좋은 게 맞을지 믿음이 없고 주저하게 된다. 흠 그래봤자 고민은 배송을 늦출 뿐. 코드를 본적이 없을 뿐 내가 생각한 방향으로도 이렇게 풀어가는 게 맞다. 구현해보자. 대학전쟁2의 수식 퍼즐처럼 적당한 공부와 적당한 도전이 코드를 짜는 것처럼 적당히 균형을 이뤄야 한다.
리팩터링하며 발견한 것.
shared_ptr<> 타입을 함수의 인자로 넘겨줄 땐 굳이 참조자로 만들 필요는 없다. 포인터이다. 레퍼런스 카운팅으로 관리되도록 하는 게 더 자연스럽다.Send가 고장났다. ???? 1시간이 넘는 디버깅 끝에 발견..! 커밋을 자주 해두니 변경점 위주로 찾을 수 있어 그래도 빠른 편이었던 것 같다.
https://github.com/qhcjfdudn/ChatProject/commit/a511929c08a5ee96e695c8be8fe9923f26946e66
참조자가 참조하는 대상이 사라질 수 있나? 아주 매우 있다.
양쪽 각각을 client1, client2라 하자. client1에서 여러 번 보낸 데이터를 client2에서 recv 하지 않고 있다가, 나중에 한번에 받게 되었다. 이거 TCP라서 이렇게 되는 것 같다. UDP였으면 지정된 데이터그램 개수 만큼 받아오지 않았을까? 나중에 UDP 구축할 때 검증해보자.
ReceiveQueue와 SendQueue를 전역적으로 싱글턴으로 사용하려고 따로 나눠서 만들어보았는데, 사실 class 디자인은 같은 코드이다. 하나로 합치면 싱글턴을 사용할 수 없다. 아? 있다.
GetReceiveStaticInstance(), GetSendStaticInstance() 2개 함수로 각각 제공하면 된다.
상위의 PacketQueue class를 만들어 상속으로 중복 코드를 제거하는 모양으로 디자인 가능하다.
→ 이 경우… PacketQueue interface or class를 사용하는 디자인 패턴 같은 것들을 적용할 수 있을 것 같지만 아직은 굳이 사용하는 것 같고, 상속 관계가 N개로 늘어날 일이 없다면 필요 없을 것 같다.
그대로 둔다. SRP를 생각하면… receive와 send는 서로 다른 호출자의 요청이기에 후에 기능이 분기될 수 있을 것으로 보고 그대로 둔다.