서버와 클라이언트에 위치한 Actor의 역할
- 클라이언트 - 서버 모델에서 항상 서버에 있는 Actor만 신뢰된다. 이를 Authority를 가진다고 표현.
- 클라이언트의 Actor는 대부분 서버 Actor를 복제한 허상이다. 이러한 Actor를 Proxy라고 한다.
이를 구분하기 위해서 현재 동작하는 어플레케이션(게임)에서의 역할을 로컬 역할(Local Role), 커넥션으로 연결된 어플리케이션에서 역할을 리모드 역할(Remote Role)이라고 한다.
리슨 서버의 경우 서버 또한 Player로서 게임에 참가하므로 어플리케이션(게임)의 게임 로직을 사용한다.
그렇다면 서버의 어플리케이션에서 Player가 존재하고 클라이언트가 추가되면 해당 클라이언트에서도 어플리케이션이 실행된다.
그럼 A는 서버의 Player, B는 클라이언트에 복제된 서버의 Player라고 한다면
A는 서버 어플리케이션의 로컬 역할, B에겐 커넥션으로 연결된 리모트 역할이 된다.
B는 클라이언트 어플리케이션의 로컬 역할, A에겐 커넥션으로 연결된 리모트 역할이 된다.
이 역할을 사용해서 서버와 클라이언트가 동일하게 사용하는 어플리케이션에서 해당 역할로 인해 클라이언트 - 서버 모드를 구현할 수 있다.
리슨 서버의 Player는 로컬 역할을 수행하면서 처리되기 때문에 네트워크 전송 과정에서 조작이 불가능하다. (신뢰성 보장)
즉, 리슨 서버의 호스트는 실제 자기 자신의 PlayerController만 사용할 수 있고 서버의 핵심 로직인 AI, 업데이트, 점수 등은 서버가 처리하는 구조이다.
어플리케이션의 게임 로직은 리슨 서버의 경우 호스트가 사용하는 서버 액터에 대해서만 게임에 관련된 작업을 수행해야한다.
Actor의 역할 종류
- None : Actor가 서버, 클라이언트 둘 다 존재하지 않음.
- Authority : 서비스를 대표하는 신뢰할 수 있는 역할, 게임 로직을 수행한다.
(서버에 존재, 게임 규칙을 관리하는 역할 - GameMode, GameState(GameState는 클라이언트에도 존재하지만 변경 권한은 서버만 가진다.)) - Autonomous Proxy : Authority를 가진 Object의 복제품. 일부 게임 로직을 수행한다.
클라이언트의 입력 정보를 서버에 보내는 역할을 수행 (W를 눌렀으니 앞으로 가게 해달라고 서버에 요청, PlayerController, Pawn) - Simulated Proxy : Authority를 가진 Object의 복제품. 게임 로직을 수행하지 않는다.
일방적으로 서버로부터 데이터를 수신해서 결과를 클라이언트에 반영만 한다. (배경 Actor ,Pawn) - Pawn은 Autonomous와 Simulated가 혼재되어 있어서 API를 통해 로직을 구분해야한다.
ex) Possess되기 전의 Pawn은 Simulated, Possess된 후 PlayeController의 패밀리가 된 이후엔 Autonomous Proxy
A클라이언트 a캐릭터는 A에서 Autonomous Proxy(입력 가능)이지만 A클라이언트에서 b, c는 Simulated Proxy이다.
Actor의 역할을 파악하는 API
- AActor::HasAuthority : 로컬 역할에서 Authority를 가진 Actor인가?
- AController::IsLocalController : 로컬에서 해당 PlayerController가 Autonomous Proxy인지 판단.
- APawn::IsLocallyControlled : 로컬에서 해당 Pawn이 Autonomous Proxy인지 판단.
NetMode에 따른 Object 배치
- 서버에만 존재하는 Actor : GameMode 등
- 서버와 모든 클라이언트에 존재하는 Actor : Simulated Proxy - 배경 Actor, Pawn 등
- 서버와 소유하는 클라이언트에만 존재하는 Actor : Autonomous Proxy - PlayerController, Pawn 등
- 클라이언트에만 존재하는 Object : 시각적인 효과를 나타내는 것들 Animation Blueprint & HUD
Unreal Engine의 커녁션 핸드세이킹(Connection Handshaking)
핸드세이킹
네트워크로 접속하는 두 컴퓨터가 잘 연결되었는지 확인하는 과정.
악수하듯 클라이언트와 서바가 정보를 주고받는다고 해서 핸드세이킹이다.
Unreal Network Multiplay 접속을 위한 핸드세이킹 과정
(NMT_~들은 DataChannel.h에 정의되어있다.)
- 클라이언트가 서버에 접속할 때 UPendingNetGame::SendInitialJoin()이라는 함수를 호출하여
NMT_Hello라는 패킷을 서버에 보낸다. - 클라이언트에서 보낸 패킷을 서버에선 UWorld::NotifyControlMessage()함수를 통해 받은 패킷을 처리
이 함수를 통해 NMT_Hello 패킷을 받은 것이 확인이 되면 클라이언트에게 NMT_Challenge라는 패킷을 보낸다. - 클라이언트의 UPendingNetGame::NotifyControlMessage()함수를 통해 NMT_Challenge 패킷을 확인하고
NMT_Login(로그인 요청)을 서버에 보낸다. - 서버에서 NMT_Login요청을 받으면 수락할지 거절할지 결정하는 AGameModeBase::PreLogin()을 호출한다.
- 서버에서 수락하면 AGameModeBase::WelcomePlayer()함수를 호출하여 클라이언트에게 NMT_Welcom 패킷을 보낸다.
- NMT_Welcome 패킷을 클라이언트가 받으면 UPendingNetGame::NotifyControlMessage()함수를 통해
서로의 속도(대역폭)를 조절할 수 있는 NMT_NetSpeed 패킷을 서버에 보낸다. - 서버가 NMT_NetSpeed 패킷을 받으면 이제 서로 원할하게 통신하도록 세팅이 진행된다.
Unreal Network Multiplay 접속 이후 로그인 진행 과정
접속이 끝나면 게임을 시작할 수 있도록 필요한 준비 과정이 있다.
클라이언트 : 맵의 로딩 / 서버 : 클라이언트를 대표할 PlayerController 생성
- 클라이언트는 UEngine::TickWorldTravel을 통해 맵을 로딩한다.
- 맵의 로딩이 끝나면 UPendingNetGame::TravelCompleted가 호출이 되고
UPendingNetGame::SendJoin()함수를 통해 NMT_Join 패킷을 서버에 보낸다. - NMT_Join 패킷을 받은 서버는 UWorld::SpawnPlayActor() 함수를 호출한다.
해당함수에서 AGameModeBase의 Login, PostLogin 함수가 호출된다.
그러므로 SpawnPlayActor를 통해 PlayerController와 Pawn이 생성된다.
알아두면 좋은 Unreal Network System 구성 (NetDrivet.h)
용도에 따라 패킷을 처리하는 다양한 NetDriver 클래스를 제공함.
- GameNetDriver : 게임 데이터를 처리하는데 사용하는 네트워크 드라이버
Unreal Engine은 GameNetDriver로 IpNetDriver 사용. - DemoNetDriver : 게임 리플레이 데이터를 처리하는데 사용되는 네트워크 드라이버
- BeaconNetDriver : 게임 외 데이터를 처리하는데 사용되는 네트워크 드라이버
Unreal Engine에서 번치(Bunch)를 처리하는데 사용하는 주요 채널
- ControlChannel : 클라이언트 - 서버 간의 커넥션을 다룰 때 사용하는 채널
초기 접속에 관련된 데이터 패킷은 ControlChannel을 통해 분석. - ActorChannel : 액터 리플리케이션 작업을 다룰 때 사용하는 채널
- VoiceChannel : 음성 데이터를 전달할 때 사용
