게임 렉 백서 › 동기화 설계
너무 엄격한 서버 검증 Over-strict server validation
원인 ID sy-strict-check · 주 담당 게임개발팀·서버 개발
그림과 실험이 있는 원본 카드로 열기 →
이동 속도·쿨타임·사거리를 서버가 너무 엄격하게 검사하면, 지터로 몰려 온 정상 입력까지 거절합니다.
왜 “한 틱에 이동 가능한 거리”, “쿨타임 0ms 허용” 같은 엄격한 기준 → 그러면 지터로 명령 두 개가 한 틱에 몰려 도착하면 규칙 위반으로 판정 → 화면에서는 고무줄, 쿨타임 됐는데 스킬 거절
- 증상
- 고무줄, 씹힘·롤백
- 요인
- 지터
- 누가 겪나
- 나만
- 언제
- 가끔 무작위로, 이동 중·지역 전환 때
- 담당
- 주 담당 게임개발팀·서버 개발
- 게임개발팀 할 일
- 누적 허용량(토큰 버킷) 방식으로 검사, 핑·지터만큼 여유 두기.
- 그래프에서는
- 가끔 무작위로 튐 · 서버 검증 거절·위치 보정 수
- 확인할 곳
- 서버 로그에 검증 거절·위치 보정마다 사유, 그 틱에 도착한 그 유저의 명령 수, 직전 명령과의 도착 간격을 남김
- 이러면 맞음
- 거절·보정이 한 틱에 명령이 2개 이상 몰려 도착한 순간에 몰리고 몇 초 단위로 합친 이동량·사용 횟수는 규칙 안에 있음
- 이러면 아님
- 몇 초 단위로 합쳐도 규칙을 넘으면 실제 과속·치트 가능성. 거절이 특정 통신사와 저녁 시간에 몰리면 특정 통신사 사용자에게 몰리는 검증 오탐 쪽
- 확인 수단
- 게임 서버·클라이언트의 로그·지표가 필요
출처
- Source SDK 2013: player.cpp Valve
틱마다 쌓이는 명령 처리 예산(최대 sv_maxusrcmdprocessticks 24틱)으로 몰려 온 명령을 허용. 더 엄격하게 막으면 정상 유저도 뚝뚝 끊김을 겪었다는 개발 주석 - RFC 2697: A Single Rate Three Color Marker IETF
토큰 버킷: 평균 속도(CIR)와 한 번에 허용하는 버스트 크기(CBS)로 판정
함께 보면 좋은 원인
같은 층: 동기화 설계
같은 증상(고무줄)의 다른 층 원인
그림과 실험이 있는 원본 카드 보기