백그라운드/메인 쓰레드 그리고....

1.
[게임 로직은 반드시 메인 쓰레드(게임 쓰레드)에서 실행되어야 한다]는 규칙만 유니티에서 정해둔 것이고,
세부적인 구현 방법은 우리의 자유입니다.
우리가 그냥 아무 위화감 없이 사용하던 모든 C# 코드들은
다 유니티 게임 쓰레드에서 실행되고 있었기 때문에,
이것에 대해 고민을 할 필요가 없었습니다.

그런데 네트워크 비동기 AsyncSend/AsyncRecv를 호출하면,
완료 통지 Handler함수가 다른 쓰레드에서 실행이 되니 문제가 발생합니다.
이 쓰레드는 게임 쓰레드가 아니기 때문에 여기서 유니티와 연관된 코드에 접근해서 뭘 하려고 나면 바로 에러가 납니다.
따라서 네트워크 Handler 쓰레드에서는 직접적으로 게임 로직을 실행하지 않고,
특정 네트워크 메시지가 왔다는 사실을 기록하기 위해
Packet class로 만든 다음에 이를 Queue에다가 넣기만 합니다.
결국 한참 지나서 게임 쓰레드에서 여유가 될 때  꺼내서 처리하는  방식으로  진행이 되겠죠.

CEO 비서실에 매우 중요한 업무 내용을 전화로 알려주면,
그것을 비서가 마음대로 처리하지 않고
전화 내용을 메모지에 적어 CEO 책상에 올려놓고
나중에 CEO가 시간 될 때 알아서 처리하길 기대하겠죠.
지금 처리 방식이 이와 유사합니다.

2.
어떤 네트워크 메시지가 왔을 때,
첫 2바이트/2바이트를 읽어서 size/protocolID를 추출하고
protocolID에 따라서 처리할 패킷 내용을 파싱을 해서 class로 만들어준 다음,
그것을 Handler로 전달해주고 있습니다.
HandlePacket을 자동화하지 않는다면
protocolID에 따라서 내용을 파싱하는 부분을 switch-case로 일일히 수동으로 만들어줘야 하는데
이런 노가다를 피하기 위해 만든 것입니다. (그런데 실제로 switch-case 200개로 처리하는 곳도 있긴 합니다)

서버 쪽에서는 [protocolID 읽기] -> [파싱 패킷 만들기] -> [handler로 넘기기]를 한 번에 하는 반면,
유니티 쪽은  [protocolID 읽기] -> [파싱 패킷 만들기] 까지만 한 다음 Queue에다 넣고,
게임 쓰레드에서 Queue 내용을 뽑아와서 다시 [handler로 넘기기]를 나눠서 하는 차이는 있지만
결과적으로 자동화된 부분을 사용하지 않는 것은 아닙니다.

참고로 이 부분은 Part7에서 다시 다루게 됩니다.
(자체 제작 프로토콜 -> protobuf로 이식하는 과정에서 다시 설명합니다)

3.
C++과 다르게 C#에서는 자체적으로 관리하는 쓰레드 풀이 있는데
그걸 사용하고 있기 때문에 별도로 만들어줄 필욘 없습니다.
(물론 쓰레드를 몇개 사용할 것인지 세부적으로 설정은 할 수 있긴 합니다)

4.
TLS는 필요에 따라 사용하는거지 꼭 이용해야 한다는 의미는 아니고,
대부분 너무 쓰레드 경합이 심한 부분에서 유용한 경우가 있지만
이것도 케바케로 다르기 때문에 뭔가를 공식화 하긴 애매합니다.
그리고 Part4에선 SendBuffer가 TLS을 이용하는 방식으로 구현이 되었는데,
스포일러를 드리자면 지금 만들고 있는 Part7에서
ProtoBuf로 SendBuffer를 대체할 예정이라 그나마 사용하던 TLS도 사라질 예정입니다.