Quy tắc truyền lại tự xây trên UDP mà quá thận trọng thì khôi phục chậm, còn quá mạnh tay thì càng làm nghẽn đường truyền.
Vì sao Khoảng cách truyền lại, số lần thử và kích thước cửa sổ được cấu hình không hợp với đường truyền → Dẫn đến Khôi phục chậm, hoặc gửi trùng lặp làm tắc nghẽn nặng thêm → Trên màn hình Nuốt skill, tua nhanh, lag nặng hơn khi mạng tắc nghẽn
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: truyền lại dựa trên thời gian khứ hồi đo được, tách kênh theo mức độ quan trọng. Client: áp dụng cùng cấu hình truyền lại và kênh như server.
Trên đồ thị
Thỉnh thoảng vọt lên bất chợt · Tỷ lệ truyền lại của UDP tin cậy, RTT trong game
Chỗ cần xem
Thống kê theo từng kết nối của thư viện đang dùng (số lần truyền lại, thời gian khứ hồi ước tính, thời gian chờ truyền lại), ghi lại ở server và client rồi so với tỷ lệ mất gói thực tế trên đường truyền của cùng người chơi (đo bằng mtr)
Đúng nếu
tỷ lệ truyền lại cao gấp mấy lần tỷ lệ mất gói thực tế (cấu hình quá mạnh tay), hoặc thời gian chờ truyền lại gấp mấy lần thời gian khứ hồi đo được (cấu hình quá thận trọng)
Loại trừ nếu
tỷ lệ truyền lại gần bằng tỷ lệ mất gói trên đường truyền và thời gian chờ khớp với thời gian khứ hồi (cấu hình vẫn ổn). Xem chính việc 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 GuidelinesIETF Truyền lại có thể làm tắc nghẽn nặng thêm nên phải chịu kiểm soát tắc nghẽn; thời gian khứ hồi được ước tính bằng trung bình của nhiều lần đo (EWMA), giá trị ban đầu 1 giây; hạ tốc độ gửi khi timer hết hạn