Lỗi matchmaking hoặc phân bổ region Wrong region assignment (matchmaking / GeoDNS)
ID nguyên nhân in-region-match · 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), Hạ tầng mạng (Đội hạ tầng), Bên ngoài (Bên ngoài)
Nếu bị xếp vào server ở region xa thay vì region gần, dù đường truyền vẫn ổn, riêng người chơi đó luôn có ping cao.
Vì sao Dữ liệu GeoIP sai, VPN, xếp cả tổ đội theo ping trung bình của các thành viên, quy tắc mở rộng sang region xa khi thiếu người, phân bổ theo vị trí của DNS resolver → Dẫn đến Kết nối vào server ở region bên kia đại dương dù có region gần hơn → Trên màn hình Trong game đặt server ở nhiều region, chỉ riêng bạn (hoặc chỉ tổ đội của bạn) luôn có ping cao, bị trễ thao tác, kéo ngược, nuốt skill
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), Hạ tầng mạng (Đội hạ tầng), Bên ngoài (Bên ngoài)
Việc cần làm (Đội phát triển game)
Server: phân bổ theo ping tới từng region do client đo thay cho GeoIP, đặt giới hạn ping tối đa cho quy tắc mở rộng sang region xa, với tổ đội thì xem cả ping cao nhất trong tổ đội bên cạnh ping trung bình, ghi log region đã phân bổ và ping lúc đó. Client: đo ping tới từng region bằng UDP rồi gửi kèm yêu cầu ghép trận, hiển thị region đang kết nối và ping trên màn hình, cho phép người chơi tự chọn region.
Việc cần làm (Đội hạ tầng)
Nếu chọn region bằng DNS: kiểm tra DNS có thẩm quyền (authoritative DNS) có hỗ trợ EDNS Client Subnet không (nếu resolver người chơi dùng không gửi thông tin này thì sẽ phân bổ theo vị trí resolver), cập nhật cơ sở dữ liệu GeoIP định kỳ, gắn quốc gia và ASN theo GeoIP vào log kết nối của server từng region để tìm các quốc gia, nhà mạng đang bị đưa sang region xa.
Việc cần làm (Bên ngoài)
Hướng dẫn người chơi tắt VPN, phần mềm tăng tốc game rồi kết nối lại, hướng dẫn người chơi đang dùng DNS công ty hoặc DNS nước ngoài đổi sang DNS của nhà mạng, yêu cầu nhà cung cấp GeoIP sửa vị trí sai.
Con số tham khảo
Người chơi ở Seoul bị xếp vào region miền Tây nước Mỹ thay vì Tokyo thì ping tăng từ khoảng 30 ms lên khoảng 130 ms. GeoIP đúng khoảng 99,8% ở cấp quốc gia, nhưng ở cấp thành phố thì ngay cả tại Mỹ, tỷ lệ nằm trong phạm vi 50 km cũng chỉ khoảng 66%, và khi người chơi dùng VPN thì GeoIP trả về vị trí của server VPN thay cho vị trí người chơi.
Trên đồ thị
Chỉ một phần cao · RTT (ping) theo người chơi, phân bố region được phân bổ
Chỗ cần xem
Gắn quốc gia và ASN theo GeoIP vào IP client trong nhật ký kết nối của server từng region (access log của bộ cân bằng tải, VPC flow log), rồi đếm xem mỗi quốc gia, nhà mạng kết nối vào region nào. Nếu chỉ có một người chơi: so sánh region người đó thực sự kết nối với ping đo tới region gần (người chơi tự đo, hoặc chạy mtr từ server ở region đó tới IP người chơi)
Đúng nếu
người chơi hoặc quốc gia có RTT cao đang kết nối vào region xa thay vì region gần, trong khi ping đo tới region gần thì thấp
Loại trừ nếu
đã được phân bổ đúng vào region gần mà ping vẫn cao → xem định tuyến đi đường vòng hoặc đường truyền, Wi-Fi của người chơi đó
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
Tìm hiểu thêm
Cách chọn region bằng DNS (DNS theo vị trí địa lý hoặc theo độ trễ) đoán vị trí dựa trên địa chỉ của DNS resolver mà người chơi dùng, thay vì địa chỉ của chính người chơi. Nếu resolver không hỗ trợ EDNS Client Subnet (cơ chế chuyển tiếp một phần địa chỉ người chơi), người chơi dùng DNS công ty hoặc DNS ở xa sẽ được phân bổ theo nơi đặt resolver. Hệ thống ghép trận cũng có thể đánh giá tổ đội bằng ping trung bình của các thành viên, hoặc nới tiêu chí ping khi chờ lâu rồi xếp vào region xa. Ở AWS GameLift Servers, tiêu chí mặc định cho ping của tổ đội cũng là trung bình, và tài liệu lấy ví dụ cấu hình nới giới hạn ping từ 50 ms lên 100 ms rồi 200 ms. Người chơi bật VPN có thể vừa bị cộng thêm độ trễ do đi qua server trung chuyển (“Đi qua VPN hoặc phần mềm tăng tốc game”) vừa bị xếp vào region xa, nên cần phân biệt bằng cách tắt VPN, kết nối lại và xem region được phân bổ có thay đổi không. Trường hợp không có region nào ở gần nên phải kết nối tới region xa được trình bày ở “Độ trễ lan truyền (khoảng cách vật lý)”.
Nguồn
RFC 7871: Client Subnet in DNS QueriesIETF DNS trả lời khác nhau theo vị trí sẽ đoán vị trí bằng địa chỉ của resolver gửi truy vấn, nên nếu người dùng dùng resolver trung tâm ở xa thì câu trả lời không phù hợp. EDNS Client Subnet (tính năng tùy chọn) chuyển tiếp một phần địa chỉ người dùng
How Amazon Route 53 uses EDNS0 to estimate the location of a userAWS Nếu resolver không hỗ trợ edns-client-subnet, vị trí người dùng được đoán bằng địa chỉ resolver và câu trả lời dựa theo vị trí resolver (chung cho định tuyến theo vị trí địa lý và theo độ trễ)
Geolocation accuracyMaxMind Cấp quốc gia khoảng 99,8%, cấp thành phố ở Mỹ (trong phạm vi 50 km) khoảng 66%; dùng VPN thì ra vị trí server VPN thay cho người dùng cuối; IP mạng di động được dùng trên vùng rộng nên không xác định được vị trí chi tiết; cơ sở dữ liệu phải được cập nhật liên tục; có thể yêu cầu sửa
FlexMatch rule typesAWS Quy tắc độ trễ (maxLatency) xem độ trễ của người chơi theo từng vị trí, tổ đội mặc định dùng trung bình của các thành viên (partyAggregation avg), hàng chờ có thể xếp cả vào region không thỏa quy tắc độ trễ
Create a player latency policyAWS Xếp vào vị trí có độ trễ trung bình của mọi người chơi thấp nhất nhưng người chơi có độ trễ cực cao vẫn được xếp vào; ví dụ chính sách nới giới hạn ping từ 50 ms lên 100 ms rồi 200 ms
Amazon GameLift Servers UDP ping beaconsAWS Client game đo độ trễ tới endpoint UDP đặt ở từng vị trí hosting rồi dùng để xếp chỗ và ghép trận, gần với lưu lượng game thực hơn ping ICMP
Azure network round-trip latency statisticsMicrosoft Azure Trung vị thời gian khứ hồi đo thực tế tính từ Seoul (Korea Central): Tokyo (Japan East) 29 ms, miền Tây nước Mỹ 124–136 ms
Flow log recordsAWS srcaddr trong bản ghi VPC flow log: với lưu lượng đi vào là địa chỉ IP bên gửi