1. 세션 매니저(유저 매니저)
세션을 관리하는 매니저 클래스.
2. 멀티 스레드 환경에서 발생하는 여러가지 상황들
(1) 상황 - 플레이어의 피격
인게임에서 플레이어 캐릭터(10번) 주위에 몬스터(5)와 다른 플레이어가 있다고 생각해보자.
그 몬스터에게 피격당한 플레이어의 정보를 어디로 보내야 할까?
->10번 캐릭터가 5번 몬스터에게 피격당했다는 정보를 해당 캐릭터 '주위'의 캐릭터도 받아야 한다.
(브로드캐스팅 한다 <-> TCP의 브로드캐스팅과는 다름)
이럴 때에는 세션 매니저에서 10번 캐릭터의 정보에 접근해 정보를 수정하고 외부의 클라이언트와 통신하면 된다.
(2) 상황 - 플레이어에게 귓속말
각 스레드를 부여받은 클라이언트들이 모두 동시에 10번 플레이어에게 귓속말을 날리고 싶다.
이 때, 유저 매니저는 Thread-Safe 할까? 아니면 락을 걸어 관리해줘야 할까?
-> 멀티 스레드가 유저 매니저에 접근해 정보를 동시에 수정하려 할 것이므로, 락을 걸어 관리해야 한다.
(3) 상황 - 필드 상에서 몬스터를 관리하는 스레드
필드 상에서 여러가지 몬스터를 관리하는 스레드 하나를 배치했다면 이것은 싱글 스레드 환경이다.
그렇다면 해당 필드에 플레이어를 배치하여 스킬을 사용하는 상황을 생각해보자.
이 상황에서는 플레이어가 스킬을 사용했다는 것을 어떻게 통신할 것인가?
-> 스킬을 사용하는 작업(일감)을 큐에 저장하여 해당 스레드가 나중에 실행한다.
ㄴ> 그렇다면 큐는 동시에 접근할 수 있으므로 Thread-Safe 하지 않으므로 락을 처리해줘야 한다.
(4) 상황 - 필드가 하나로 합쳐졌을 때 멀티 스레드 관리
각 필드와 스레드가 1:1으로 관리되고 있었다.
그 때 사양이 변경되여 어떤 두 개의 필드가 하나로 합쳐지는 상황이다.
이럴 때 어떤 스레드가 해당 필드를 담당해야 하는가?
-> 락을 걸어서 두 스레드가 각각 처리한다.
-> 모든 액터들에 큐를 두고 각 액터마다 스레드가 왔다갔다하며 처리하게 한다.
=> 사실 싱글 스레드로 만들어 처리하는게 더 편할 수도 있다..
3. 커맨드 패턴(Command Pattern)
디자인 패턴 중 하나이다.
각 작업 요청(Job, Task)을 객체로 만들어 관리한다. 이후에 큐에 저장하고 불러와서 작업을 처리한다.
몬스터의 이동, 공격 등의 작업도 해당 큐에 넣어 처리하게 된다.
'서버 프로그래밍 > 네트워크' 카테고리의 다른 글
2-7. 소켓 입출력 모델 (3) - IOCP(Input/Output Completion Port) (0) | 2023.12.04 |
---|---|
2-6. 소켓 입출력 모델 (2) - Overlapped 모델 (0) | 2023.12.01 |
2-5. 소켓 입출력 모델 (1) - Select 모델 (Select, WSAEventSelect) (0) | 2023.11.30 |
2-4. 소켓 옵션 설정, 논-블로킹 소켓(Non-Blocking Socket) (0) | 2023.11.30 |
2-3. TCP와 UDP (0) | 2023.11.29 |