게임 네트워킹의 이해3 - 받은 데이터 활용 방식

네트워크를 통해 전송된 데이터의 활용 방식

---

Deterministic 방식

같은 인풋을 가지고 있으면 두 개의 다른 컴퓨터가 똑같은 게임 결과를 가지고 있다는 가정을 하는 것이다.
플레이어 1이 입력한 인풋과 플레이어2가 입력한 인풋이 두 pc에 동일하게 적용되면 두 pc의 결과가 같다. ( sync가 맞다 )
그런데 두 pc의 latency가 있는데 이 latency에 의해서 두 pc의 입력이 다르게 처리된다 하면 결과 상태가 달라지게 된다.
이렇게 되면 sync가 안 맞게 되는데 이걸 막는 방법이 deterministic 방식의 가장 중요한 요소이다.

• 이미 결정되어 있다!
• 같은 입력이 같은 시간에 두 개의 pc에 들어가게 만들면 결과는 같다. (ex. 오락실의 두 대의 마주보고 있는 철권 게임기 )
• 상태를 주고받는 게 아니라 입력을 주고받는다.
• 재접속했을 때 현재 내 상태를 알기 위해서는 현재까지의 인풋을 모두 다 받아서 처리했을 때 현재 상태의 싱크를 맞출 수 있다.
• 이 방식에서는 desync를 꼭 잡아야 한다. ( 그런데 매우 구현하기가 어렵다 )
• 이 방식은 해킹에 취약하다. ( 기본적으로 input에 의존하는 방식이기 때문 )
  물론 server authority도 해킹에 취약한 건 마찬가지이지만 이 방식은 서버가 상태와 로직을 들고 있고,
  서버가 명령하는대로 수행하기 때문에 서버가 심판 역할을 하고 있다.
  그래서 좀 더 deterministic 방식보다는 input set을 수정하는 해킹 방법에서는 더 해킹에서 안전하다.
• delay + rollback 방식 / relay server 방식

1.중계 서버 방식 ( relay server, broadcast server )

서버에 여러 클라이언트가 붙으면 이 서버는 받은 패킷을 받아서 다른 클라이언트에 전달만 하는 역할을 한다.

• 반응성이 떨어짐 ( 딜레이가 길어짐 )
• desync가 일어날 확률이 적고 구현이 쉽다.
• 상태를 저장할 필요가 없다. 그냥 패킷을 받으면 받아서 발송만 하기 때문!
• AOS, 스포츠 게임 등은 반응성이 조금 느려도 괜찮아서 여기서 쓰인다.

어떤 클라에서 버튼이 눌렸다는 정보를 서버가 받으면 서버가 모든 클라이언트에게 이 정보를 보낸다.
각 클라이언트들은 서버로부터 패킷을 받았을 때 그 패킷에 의존해서 처리하게 된다.
모든 클라이언트는 똑같은 입력을 받게 된다. 즉, 모든 클라가 같은 인풋을 받게 되므로 deterministic이 성립된다.

서버는 예를 들어 1초에 30개, 60개 등등의 인풋을 게더링해서 쌓아두고 정해둔 시간 간격인 1초가 될때 모아둔 인풋을
모든 클라이언트에게 발송해서 처리한다. -> 턴제라고 생각하면 편함

이 방식은 desync도 잘 일어나지 않고 구현도 쉽다.
하지만 문제점이 하나 있다.
클라는 중계 서버로 인풋을 보내고 중계서버에서 응답이 왔을 때 작업이 처리가 되는 건데 이 방식은 딜레이가 길어질 수 있다.
딜레이가 200ms 이상이 나면 사용자가 인식하게 되므로 문제가 생긴다.

Server Authority 방식

---

• 서버가 모든 권한을 가지고 있다.
• 서버가 중재자 및 심판이다.
• 클라이언트는 서버가 명령한 대로 수행하게 된다.
• mmorpg에서 많이 쓰인다. -> 동접자 수가 매우 많음
• CS ( Client - Server ) 구조
  • 웹 서버가 대표적임
• 항상 클라이언트가 요청하면 서버가 응답한다. 클라이언트가 요청을 안하면 절대 응답하지 않는다.

게임 서버는 기본적으로 CS가 서로 커넥션을 유지하는 방식으로 되어 있다.
게임 서버는 클라가 질의하는 것 외에도 서버가 스스로 noti(알림)를 클라에게 날리기도 한다.
그래서 커넥션을 맺고 유지하고 있으면서 질의-응답을 계속 하고, 중간중간 알림을 서버가 보내기도 하는 식이다.

가령 예를 들어 mmorpg를 만들 때 이동, 액션이 대표적인 동작이다.
이동할 곳을 커서를 찍으면 클라가 서버에 req(이동시켜줘)를 보낸다. 그럼 찍은 좌표를 서버에 보낸다.
서버에도 같은 상태가 그대로 있고 서버 안에서 그 유저를 이동시키고 그걸 클라에 알린다.( res(이동시작했다) )
그러면 서버에서 유저가 실시간으로 위치가 조금씩 바뀌어가는데 이걸 noti(알림)로 클라에 위치가 변경되었단 걸 알린다.
클라는 이 위치 변경을 따라가면서 이동을 화면에 보여준다.

< 문제점 >

• 이 방식에서 제일 큰 문제는 서버가 로직, 게임 월드를 모두 컨트롤해야 한다. 이게 관건이다.
  • 하나의 서버가 얼마나 많은 유저, 얼마나 큰 월드를 컨트롤 할 수 있느냐가 관건
• 10k 서버가 꿈의 서버라고 한다.
  • 만 명의 클라이언트(동접 만 명)가 하나의 서버에 접속해서 계속 유지되는 서버 (실시간으로)
  • 웹 서버 같은 경우 10000개의 req가 동시에 와도 분산되어 크게 문제가 안 되는데, 게임 서버에서는 이게 실시간으로 발생되기 떄문에 초당 한 유저한테 날라가는 패킷이 최소 10개 정도는 날라갈 수 있어야 실시간으로 볼 수 있어서, 만 명이면 초당 10만개 정도의 패킷이 날라갈 수 있어야 실시간이라고 볼 수 있다.
  • 실시간 서버를 얼마나 크게 잘 유지할 수 있는지가 게임 서버의 관건이다.

server authority 방식에서는 코드를 구현하는 것 보다 massive한 유저들을 어떻게 핸들링 할 것인지가 관건이다!!