C# 게임 서버 공부(8)

 드디어 JobQueue다.
 이걸 처음 봤을 때 느꼈던 그 황홀감이 잊혀지지 않는다.

 JobQueue의 최대 장점은 뭐니뭐니해도 lock사용을 줄여준다는 것이다.
 전에 언급했던 20년 된 게임.... 기억하기로 JobQueue는 쓰고 있었다.
 하지만 lock도 함께 열심히 쓴 덕분에 멀티쓰레드를 가장한 싱글쓰레드 게임이 되었을 뿐이었다.

 해당 강의에서도 언급한 것중 하나가 JobQueue를 사용하는 class면 lock을 모두 빼주라고 말하고 있다.
 lock이라는것 자체가 하나의 공용 데이터에 여러 쓰레드가 "내꺼야!"하면서 우다다다닥 들어가는 것이 문제다.
 하지만 JobQueue는 Job을 관리하는 하나의 쓰레드가 순서를 지키며 Job을 처리하기 때문에 굳이 lock을 적극적으로 해줄 필요는 없다.
 다만!
 JobQueue가 아니라 다른 쓰레드가 접근할 상황이면 조심해야 한다.

 한 예로 조금 억지를 들자면, 전투 상황이다.
 유저 A가 Auto상태로 전투 중이고, 이 상황은 모두 '서버'가 담당한다.
 서버가 자동으로 대상을 찾고, 서버가 몬스터와 싸우고, 서버가 아이템을 회수하고.....
 움직임은 서버가 판별하고 결과를 클라에게 보내줄 뿐이다.
 해당 로직은 JobQueue가 아니라 일정 시간마다 플레이어를 움직이는 로직이라고 하자.
 이때 유저 B가 유저 A를 공격한다 할 때 이건 네트워킹 소캣으로 들어온다.
 소캣을 JobQueue로 들어온다.
 그렇다면 여기서 유저 A가 Auto로 움직이는데, 이때 A의 정보를 조작하는 로직과 유저 B의 공격으로 HP가 줄어든 그러니까 소캣을 받고 해당 전투 상황을 처리하는 JobQueue부분이 2개로 나누어지는데, 재대로 처리하지 않으면 대환장 파티가 벌어질 수 있다.
 이때 할 수 있는 방법은 lock을 걸어 자동 전투와 소캣 데이터 처리가 동시에 접근 못하게 하는 방법과 어떤 곳이든 전투 상황을 총괄하는 하나의 JobQueue를 생성하던가 등등의 방법이 있을 것이다.

 개인적으로 lock을 걸지 않는 상황에서 로직만 생각처럼 잘 돌아가면 된다고 본다.
 lock을 저렇게 적극적으로 걸거면 JobQueue를 사용하지 않는게 맞다고 본다.

 번외로 이번 강의에서도 뭔가 걸리는 부분이 있다.

 이 부분이다.
 OnRecvCompleted()부분에서 BytesTransferred가 0인 경우가 나왔다.
 이때 확인 결과 OnRecv()에서 return하는 값을 0으로 고정하고 있었다.
 강의를 여기까지 따라온 분들은 아실텐데, read buffer를 2개의 커서를 사용해 하나는 읽는용도, 하나는 쓰는 용도로 사용한다.
 OnRecv()에서 return값이 0으로 고정되면 읽는 커서가 움직이지 않고, 프로그램은 "? 버퍼 남는자리 없음."하고 받기 실패 -> BytesTransferred가 0으로 나오게 된다.
 강의 질문 보니 이 부분 질문이 몇개 있어서 내 실수가 아니라 강사님이 실수로 빼먹은 부분일 수도 있기에 혹시 몰라 올려둔다.
 (근데 솔직히 내 실수일 확률이 많이 높다.)