Mất thông tin xuất hiện dồn tới ngay sau khi vào Initial spawn burst lost (unreliable channel, receive buffer, fragmentation)

ID nguyên nhân pt-spawn-burst · Phụ trách chính Phát triển server (Đội phát triển game) · Phối hợp Phát triển client (Đội phát triển game)

Mở thẻ gốc có hình minh họa và thí nghiệm →

Ngay khi nhân vật bước vào zone, server gửi cùng lúc thông tin xuất hiện của vài chục đến vài trăm đối tượng xung quanh. Nếu gửi chúng qua kênh không tin cậy (unreliable), hoặc bộ đệm nhận bị tràn trong lúc client đang loading nên không đọc socket, một phần sẽ biến mất và không được gửi lại.

Vì sao Ngay sau khi vào, thông tin xuất hiện dồn tới trong khoảnh khắc ngắn → Dẫn đến Client đang loading đọc socket muộn nên bộ đệm nhận của OS bị tràn, hoặc gói UDP lớn bị phân mảnh nên chỉ mất một fragment là mất cả gói. Nếu là kênh không tin cậy thì cũng không được gửi lại → Trên màn hình Chỉ ở client loading chậm hơn mới thiếu vài NPC. Ra khỏi tầm nhìn rồi quay lại thì thấy

Triệu chứng: Không hiển thị·đối tượng ma
Yếu tố: Mất gói
Ai gặp phải: Chỉ một client trên cùng PC, Chỉ mình tôi
Khi nào: Ngay sau đăng nhập hoặc bảo trì, Khi di chuyển hoặc chuyển bản đồ
Phụ trách: Phụ trách chính Phát triển server (Đội phát triển game) · Phối hợp Phát triển client (Đội phát triển game)
Việc cần làm (Đội phát triển game): Server: thông báo xuất hiện và rời đi nhất định phải gửi qua kênh tin cậy có bảo đảm truyền lại, chia nhỏ thông tin ban đầu khi gửi. Client: nhận dữ liệu trên thread tách riêng khỏi loading, tăng kích thước bộ đệm nhận.
Con số tham khảo: Giá trị mặc định của bộ đệm nhận UDP trên PC khác nhau tùy OS nhưng thường khoảng vài chục đến vài trăm KB. Nếu thông tin khi vào một thị trấn đông người lớn hơn mức này, chỉ cần vì loading mà không đọc socket trong giây lát là bị tràn.
Trên đồ thị: Tăng vọt ngay sau đăng nhập hoặc bảo trì · Lượng dữ liệu nhận ngay sau khi vào, số thông báo xuất hiện bị sót
Chỗ cần xem: So sánh số thông báo xuất hiện server gửi ngay sau khi vào với số client nhận được, và xem đã gửi qua kênh nào (tin cậy hay không tin cậy). Trong bản bắt gói phía server, xem lượng dữ liệu gửi tới người chơi đó ngay sau khi vào và các gói bị phân mảnh (filter Wireshark ip.flags.mf == 1 || ip.frag_offset > 0)
Đúng nếu: số nhận ít hơn số gửi, phần thiếu tập trung ở đoạn dồn ngay sau khi vào, và đã gửi qua kênh không tin cậy hoặc gói lớn bị phân mảnh. Xảy ra thường hơn ở client loading chậm hơn
Loại trừ nếu: số gửi và số nhận bằng nhau mà vẫn không thấy → đã bị bỏ sau khi nhận (bỏ thông báo xuất hiện tới trong lúc loading) hoặc vấn đề tính toán tầm nhìn. Thiếu liên tục, không liên quan tới lúc vừa vào → mất gói trên đường truyền
Cách kiểm tra: Cần log và chỉ số của server, client game

Nguồn

RFC 8085: UDP Usage Guidelines IETF
Gói bị phân mảnh chỉ cần mất một fragment là mất cả gói
UDP vs. TCP Gaffer On Games
UDP không bảo đảm việc truyền tới và thứ tự, gói bị mất phải tự phát hiện rồi gửi lại
Socket.ReceiveBufferSize Property Microsoft
Kích thước mặc định của bộ đệm nhận socket khác nhau tùy OS
Display Filter Reference: Internet Protocol Version 4 Wireshark
Dùng ip.flags.mf (More fragments), ip.frag_offset (Fragment Offset) để lọc các gói IP bị phân mảnh

Nguyên nhân nên xem cùng

Cùng tầng: Sự cố chỉ một số người gặp

Nguyên nhân ở tầng khác gây cùng triệu chứng (Không hiển thị·đối tượng ma)

Ổ lưu trữ chậm khiến streaming asset không theo kịp L1 Tiến trình game phía client
Keepalive mặc định 2 giờ L8 Socket và giao thức
Slow start sau thời gian nhàn rỗi L8 Socket và giao thức

Xem thẻ gốc có hình minh họa và thí nghiệm