트라이브스의 네트워킹 모델

트라이브스는 1998년에 출시된 FPS 장르의 게임이다.

이 게임은 128명 까지 접속 가능한 게임 모드를 재공했으며 이는 당시 기술로는 어려운 일이었다.

트라이브스를 만드는 데 사용된 네트워크 모델은 여전히 상당 부분 유용하다.

효율성을 문제로 비 신뢰성 프로토콜, UDP를 사용했으며, 크게 네 가지 종류로 데이터 요구 사항을 구분했다.

전달 미보장 데이터: 게임에 있어서 중요하지 않은 데이터. 네트워크 대역폭이 적으면 이 종류의 데이터부터 생략한다.

최신 상태 데이터:  지금이 아니면 의미 없는 성격의 데이터. // 현재 HP를 알고 있다면 5초 전의 HP는 중요하지 않다.

전달 보장 데이터: 수신과 순서가 보장되어야 하는 데이터. // 플레이어의 총 발사 등

특급 전달 보장 데이터: 최우선적으로 보내져야 하며 시간이 지체될 수록 정보의 가치가 떨어지지는 데이터. // 플레이어 위치 정보 등

이 게임은 P2P 대신 CS(Client-Server)모델을 채택했다. P2P 모델은 총 O(n^2)의 대역폭이 필요하지만 CS모델은 서버만 O(n)의 대역폭을 처리하면 되기 때문이다.

트라이브스에서 네트워크를 어떤 계층으로 나누었는지 살펴보자.

게임  시뮬레이션 계층

고스트 관리자 / 이동 관리자 / 이벤트 관리자 / 기타..

스트림 관리자

연결 관리자

플랫폼 패킷 모듈

플랫폼 패킷 모듈

플랫폼 패킷 모듈은 네트워킹 모델 스택 중 최하위에 위치하며, 플랫폼 소켓 API를 래핑한 것이다.

트라이브스는 비신뢰성 프로토콜을 사용하므로, 어플리케이션 단 신뢰성 구축이 필요했는데, 신뢰성 구축은 상위 계층의 관리자들과 나누어 담당한다.

연결 관리자

연결 관리자의 역할은 두 컴퓨터(서버-클라이언트) 사이의 연결을 추상화하는 것이다.

바로 윗단의 스트림 관리자가 내려주는 데이터를 받아 플랫폼 패킷 모듈로 전달한다.

연결 관리자도 신뢰성을 보장해주진 않고, 맡긴 패킷이 전달되었는지 여부까지만 상위 관리자인 스트림 관리자에게 알려준다.

스트림 관리자

상위 관리자가 보내는 데이터들은 모두 스트림 관리자에 취합되는데, 스트림 관리자는 최대 데이터 전송률을 조절해가며 데이터를 연결 관리자에 보낸다. 

스트림 관리자는 어떤 데이터를 보낼지 결정하고 패킷을 꾸리고, 연결 관리자로 부터 전송 여부를 받아 상위 관리자들에게 각자의 데이터가 잘 전달되었는지 알려준다.

전송 주기와 패킷 크기를 스트림 관리자가 결정하므로 한 패킷에 여러 종류의 데이터가 섞여있는 경우가 많다.

패킷:[이동][공격][이동]

이벤트 관리자

게임 시뮬레이션 중 발생하는 이벤트 대기열을 관리한다. 

이벤트에 우선 순위와 중요도를 매기고  우선순위가 높은 이벤트부터 기록을 하고, 중요한 이벤트의 경우는 전송 기록까지 추적해 가며 보내지지 않았다면 재전송을 하는 등의 확실한 전달을 보장한다.

예를 들어, 플레이어가 총을 쏜다고 하자. 이 때 관련 시스템이 player_fired란 이벤트를 이벤트 관리자에 보낸다. 그러면 이벤트 관리자는 이를 서버에 보내고, 서버는 이를 받아 검증한 후 실제 사격을 처리한다. 

고스트 관리자

고스트 관리자는 멀티플레이를 실현하는 데 가장 중요한 시스템이다. 

일단 고스트가 뭔지 알아보자. 클라이언트가 서버에서 받아둔 여러 객체 정보를 클라이언트 상 서버의 고스트라 칭한다. 

고스트 관리자가 하는 일은 특정 클라이언트에게 유의미하다고 여겨지는 고스트를 만들고, 고스트의 상태를 전송, 수신 하는 것이 고스트 관리자의 역할이다.

고스트 관리자는 그 클라이언트에 필요한 정보만 걸러서 보낸다. 클라이언트가 어떤 내용을 반드시 파악하고 있어야 하는지는 게임 시뮬레이션 계층이 판단한다.

이동 관리자

이동 관리자의 역할은 플레이어의 이동 데이터를 최대한 빨리 전송하는 것이다.

이동 관리자는 초당 30프레임의 빠른 속도로 입력 캡쳐를 수행하고, 이 데이터엔 높은 우선 순위가 부여된다.

스트림 관리자는 이동 데이터를 최우선 순위로 보내낸다.

기타 시스템들

그 외에는 다른 관리자들처럼 큰 비중을 차지하는 것들은 아니다. 그 중에서 하나를 꼽자면, 정적인 게임 객체의 전송을 취급하는 데이터 블록 관리자가 있다.

개인적인 생각들

0. 꼭 신뢰성이 필요한 경우는 그냥 TCP를 썼으면 안 됐을까? 훨씬 편했을 거 같은데.. 

1. 정확한 시뮬레이션을 하려면 클라와 서버와 동일한 로직이 있어야 한다. 요즘 같은 경우는 엔진을 가져다가 쓰는 경우가 많은데, 인게임 플레이의 경우는 서버 역시 클라이언트 엔진을 같이 써야할 경우가 많을 듯.