遊戲 Lag 白皮書 › 只有部分人遇到的問題
剛進場時湧入的出現資訊遺失 Initial spawn burst lost (unreliable channel, receive buffer, fragmentation)
原因 ID pt-spawn-burst · 主要負責 遊戲開發團隊（伺服器開發） · 協同 遊戲開發團隊（用戶端開發）
在含圖解與實驗的完整版中開啟卡片 →
踏進 zone 的瞬間，伺服器會一次送出周圍數十～數百個物件的出現資訊。若用不可靠（unreliable）通道送出，或在載入中無法讀取 socket 的期間接收緩衝區溢位，就會有一部分消失且不再重送。
為什麼 剛進場時，出現資訊在短時間內大量湧入 → 於是 載入中的用戶端太晚讀取 socket，使 OS 接收緩衝區溢位；或大型 UDP 封包被分段，只要遺失一個分段就整個消失。若是不可靠通道，也不會重送 → 畫面上 只有載入較慢的那個用戶端少了幾隻 NPC。離開視野再回來就看得到
- 症狀
- 看不見／幽靈物件
- 因素
- 遺失
- 誰會遇到
- 同一台電腦只有其中一個用戶端, 只有我
- 何時
- 剛登入／維護剛結束, 移動中／切換地圖時
- 負責單位
- 主要負責 遊戲開發團隊（伺服器開發） · 協同 遊戲開發團隊（用戶端開發）
- 遊戲開發團隊要做的事
- 伺服器：出現與消失通知一律用保證重傳的可靠通道送出，初始資訊分批傳送。用戶端：在與載入分開的執行緒接收，並加大接收緩衝區。
- 數值參考
- 電腦的 UDP 接收緩衝區預設值依 OS 而異，大多為數十～數百 KB。人多的城鎮進場資訊若比這更大，只要因為載入而短暫沒讀 socket 就會溢位。
- 圖表上
- 剛開服或維護結束後暴增 · 剛進場時的接收量、出現通知遺漏數
- 查看位置
- 比較伺服器剛進場時送出的出現通知數與用戶端收到的數量，並查看是用哪種通道（可靠／不可靠）送出。在伺服器端封包擷取中查看剛進場時送往該玩家的量與被分段的封包（Wireshark 篩選器 ip.flags.mf == 1 || ip.frag_offset > 0）
- 符合的跡象
- 收到的數量少於送出數量，遺漏集中在剛進場湧入的區段，且是以不可靠通道送出或大封包被分段。在載入較慢的用戶端上更常發生
- 不符合的跡象
- 送出與收到數量相同卻看不見時，是收到後被丟棄（載入中抵達的出現通知被丟棄）或視野計算的問題。與剛進場無關、隨時都會遺漏時，是線路的封包遺失
- 確認方式
- 需要遊戲伺服器／用戶端的 log 與指標
出處
- RFC 8085: UDP Usage Guidelines IETF
被分段的封包只要遺失一個分段就整個消失 - UDP vs. TCP Gaffer On Games
UDP 不保證送達與順序，遺失的封包必須自行偵測並重送 - Socket.ReceiveBufferSize Property Microsoft
socket 接收緩衝區的預設大小依 OS 而異 - Display Filter Reference: Internet Protocol Version 4 Wireshark
以 ip.flags.mf（More fragments）、ip.frag_offset（Fragment Offset）篩選被分段的 IP 封包
相關原因
同一層：只有部分人遇到的問題
同一症狀（看不見／幽靈物件）在其他層的原因
查看含圖解與實驗的完整版卡片