한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

게임 렉 백서 › 일부에게만 생기는 문제

입장 직후 몰리는 등장 정보 유실 Initial spawn burst lost (unreliable channel, receive buffer, fragmentation)

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

그림과 실험이 있는 원본 카드로 열기 →

존에 들어서는 순간 서버는 주변 개체 수십~수백 개의 등장 정보를 한꺼번에 보냅니다. 이 정보를 비신뢰(unreliable) 채널로 보내거나, 로딩 중이라 소켓을 못 읽는 사이 수신 버퍼가 넘치면 일부가 사라지고 다시 오지 않습니다.

왜 입장 직후 등장 정보가 짧은 순간에 몰려 도착 → 그러면 로딩 중인 클라이언트가 소켓을 늦게 읽어 OS 수신 버퍼가 넘치거나, 큰 UDP 패킷이 단편화되어 프래그먼트 하나만 잃어도 통째로 사라짐. 비신뢰 채널이면 다시 보내 주지도 않음 → 화면에서는 로딩이 느린 쪽 클라이언트에서만 NPC 몇 마리가 빠짐. 시야를 벗어났다 돌아오면 보임

증상
안 보임·유령 개체
요인
손실
누가 겪나
같은 PC의 한쪽 클라만, 나만
언제
접속·점검 직후, 이동 중·지역 전환 때
담당
주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일
서버: 등장·퇴장 알림은 반드시 재전송이 보장되는 신뢰 채널로, 초기 정보는 나눠서 보내기. 클라이언트: 수신은 로딩과 별개의 스레드에서, 수신 버퍼 크기 늘리기.
수치 감각
PC의 UDP 수신 버퍼 기본값은 OS마다 다르지만 대개 수십~수백 KB입니다. 사람 많은 마을의 입장 정보가 이보다 크면, 로딩 때문에 소켓을 잠깐만 못 읽어도 넘칩니다.
그래프에서는
접속·점검 직후 폭증 · 입장 직후 수신량, 등장 알림 누락 수
확인할 곳
서버가 입장 직후 보낸 등장 알림 수와 클라이언트가 받은 수를 비교하고 어느 채널(신뢰·비신뢰)로 보냈는지 봄. 서버 쪽 패킷 캡처에서 입장 직후 그 유저에게 간 양과 단편화된 패킷(Wireshark 필터 ip.flags.mf == 1 || ip.frag_offset > 0)을 봄
이러면 맞음
받은 수가 보낸 수보다 적고 빠진 것이 입장 직후 몰린 구간에 모여 있으며, 비신뢰 채널로 보냈거나 큰 패킷이 단편화되어 있음. 로딩이 느린 쪽 클라이언트에서 더 자주 생김
이러면 아님
보낸 수와 받은 수가 같은데 안 보이면 받은 뒤 버린 것(로딩 중 도착한 등장 알림 폐기)이나 시야 계산 문제. 입장 직후와 상관없이 수시로 빠지면 회선 손실
확인 수단
게임 서버·클라이언트의 로그·지표가 필요

출처

  1. RFC 8085: UDP Usage Guidelines IETF
    단편화된 패킷은 프래그먼트 하나만 잃어도 통째로 사라짐
  2. UDP vs. TCP Gaffer On Games
    UDP는 전달·순서를 보장하지 않아 잃은 패킷은 직접 감지해 다시 보내야 함
  3. Socket.ReceiveBufferSize Property Microsoft
    소켓 수신 버퍼 기본 크기는 OS마다 다름
  4. Display Filter Reference: Internet Protocol Version 4 Wireshark
    ip.flags.mf(More fragments)·ip.frag_offset(Fragment Offset)로 단편화된 IP 패킷을 거름

함께 보면 좋은 원인

같은 층: 일부에게만 생기는 문제

같은 증상(안 보임·유령 개체)의 다른 층 원인

그림과 실험이 있는 원본 카드 보기