기준 스냅샷 유실 Lost baseline for delta compression

원인 ID pt-baseline · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발

서버가 “지난번과 달라진 것만” 보내는 방식에서, 처음 한 번 보내는 전체 정보(기준)를 잃으면 그 뒤 변화분을 적용할 수 없습니다.

왜 개체의 전체 정보(기준) 패킷이 손실되거나 처리 전에 버려짐 → 그러면 클라이언트가 이후의 변화분을 적용할 대상이 없어 무시 → 화면에서는 그 개체가 안 보이거나, 한참 뒤 갑자기 나타남

증상: 안 보임·유령 개체, 순간이동
요인: 손실
누가 겪나: 같은 PC의 한쪽 클라만, 나만
언제: 가끔 무작위로
담당: 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일: 서버: 기준은 수신 확인(ACK)을 받을 때까지 반드시 재전송, 변화분은 클라이언트가 받았다고 확인한 기준을 바탕으로만 만들기. 클라이언트: 기준은 실제로 적용한 뒤에 수신 확인(ACK) 보내기, 모르는 개체의 변화분을 받으면 서버에 다시 요청.
그래프에서는: 가끔 무작위로 튐 · 모르는 개체의 변화분 수신 수
확인할 곳: 클라이언트가 기준 없이 받은 변화분을 버린 횟수와 개체 ID를, 서버가 그 개체의 기준을 보낸 시각·ACK를 받은 시각과 대조. 개발 환경에서 손실을 넣어(tc netem의 loss, Unreal 네트워크 에뮬레이션의 패킷 손실 비율) 재현
이러면 맞음: 서버는 안 보이는 개체의 기준을 보냈지만 ACK를 받지 못했는데도 변화분만 계속 보냈고, 클라이언트는 그 변화분을 버림
이러면 아님: 기준이 ACK까지 받고 클라이언트에 적용됐는데 안 보이면 퇴장 알림 유실이나 개체 ID 재사용 혼동
확인 수단: 게임 서버·클라이언트의 로그·지표가 필요

출처

Snapshot Compression Gaffer On Games
변화분은 상대가 받았다고 확인(ack)한 기준(baseline)을 바탕으로만 만들어야 하고, 초기 상태는 따로 보냄
Quake III Arena source: code/server/sv_snapshot.c id Software
클라이언트가 확인한 스냅샷을 기준으로 델타 압축하고 기준이 너무 오래되면 전체 스냅샷을 보냄
tc-netem(8) — Linux manual page iproute2
나가는 패킷에 지연·지터(delay TIME JITTER)와 손실(loss random PERCENT)을 넣어 실제 네트워크를 흉내 내는 시험 도구
Using Network Emulation in Unreal Engine Epic Games
서버·클라이언트에 최소·최대 지연과 패킷 손실 비율을 넣어 시험, 콘솔에서는 NetEmulation.PktLag처럼 설정