คู่มือเกมแลค › L13 สถาปัตยกรรมเซิร์ฟเวอร์และการดูแลระบบ
matchmaking/การจัดรีเจียนผิดพลาด Wrong region assignment (matchmaking / GeoDNS)
ID สาเหตุ in-region-match · ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ พัฒนาไคลเอนต์ (ทีมพัฒนาเกม), อินฟราเครือข่าย (ทีมอินฟรา), ภายนอก (ภายนอก)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
ถ้าถูกจัดไปเซิร์ฟเวอร์ในรีเจียนที่ไกลแทนรีเจียนที่ใกล้ ผู้เล่นคนนั้นจะปิงสูงตลอดแม้เน็ตจะปกติ
ทำไม ข้อมูล GeoIP ผิด, VPN, จัดทั้งปาร์ตี้ตามปิงเฉลี่ยของสมาชิก, กฎที่ขยายไปถึงรีเจียนไกลเมื่อคนไม่พอ, การจัดตามตำแหน่งของ DNS resolver → ผลคือ มีรีเจียนที่ใกล้อยู่แล้ว แต่ไปเชื่อมต่อกับเซิร์ฟเวอร์ในรีเจียนข้ามทะเล → บนหน้าจอ ในเกมที่มีเซิร์ฟเวอร์หลายรีเจียน เราคนเดียว (หรือแค่ปาร์ตี้เรา) ปิงสูงตลอด และมีอินพุตดีเลย์, โดนดีดกลับ, สกิลไม่ออก
อาการ อินพุตดีเลย์ , ดีดกลับ , กดไม่ติด/โรลแบ็ค ปัจจัย ความหน่วง
ใครเจอ เราคนเดียว, บางพื้นที่/บาง ISP
เกิดเมื่อไร ตลอดเวลา, หลังล็อกอิน/หลังปิดปรับปรุง
ผู้รับผิดชอบ ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ พัฒนาไคลเอนต์ (ทีมพัฒนาเกม), อินฟราเครือข่าย (ทีมอินฟรา), ภายนอก (ภายนอก)
งานฝั่งทีมพัฒนาเกม เซิร์ฟเวอร์: จัดรีเจียนตามปิงแต่ละรีเจียนที่ไคลเอนต์วัดได้แทน GeoIP, ใส่เพดานปิงในกฎที่ขยายไปรีเจียนไกล, ปาร์ตี้ให้ดูปิงของสมาชิกที่สูงที่สุดด้วยนอกจากค่าเฉลี่ย, เก็บ log รีเจียนที่จัดให้และปิงในตอนนั้น ไคลเอนต์: วัดปิงแต่ละรีเจียนด้วย UDP แล้วส่งไปพร้อมคำขอจับคู่, แสดงรีเจียนที่เชื่อมต่อและปิงบนหน้าจอ, มีตัวเลือกให้เลือกรีเจียนเอง
งานฝั่งทีมอินฟรา ถ้าใช้ DNS เลือกรีเจียน ให้ตรวจว่า authoritative DNS รองรับ EDNS Client Subnet หรือไม่ (ถ้า resolver ที่ผู้เล่นใช้ไม่ส่งมา จะจัดตามตำแหน่งของ resolver), อัปเดตฐานข้อมูล GeoIP เป็นประจำ, ใส่ประเทศและ ASN จาก GeoIP ลงใน log การเชื่อมต่อของเซิร์ฟเวอร์แต่ละรีเจียน เพื่อหาประเทศและ ISP ที่ไปลงรีเจียนไกล
งานฝั่งภายนอก แนะนำให้ผู้เล่นปิด VPN หรือโปรแกรมลดปิงแล้วลองเชื่อมต่อใหม่, แนะนำผู้เล่นที่ใช้ DNS ของบริษัทหรือของต่างประเทศให้ลองเปลี่ยนไปใช้ DNS ของ ISP, แจ้งผู้ให้บริการ GeoIP ให้แก้ตำแหน่งที่ผิด
ตัวเลขที่ควรรู้ ถ้าผู้เล่นในโซลถูกจัดไปรีเจียนสหรัฐฯ ฝั่งตะวันตกแทนโตเกียว ปิงจะเพิ่มจากประมาณ 30 ms เป็นประมาณ 130 ms GeoIP ถูกต้องระดับประเทศประมาณ 99.8% แต่ระดับเมือง แม้ในสหรัฐฯ สัดส่วนที่อยู่ในรัศมี 50 กิโลเมตรมีเพียงประมาณ 66% และถ้าใช้ VPN จะได้ตำแหน่งของเซิร์ฟเวอร์ VPN แทนตำแหน่งผู้เล่น
บนกราฟ จุดที่ต้องดู ใส่ประเทศและ ASN จาก GeoIP ให้ IP ของไคลเอนต์ใน log การเชื่อมต่อของเซิร์ฟเวอร์แต่ละรีเจียน (access log ของโหลดบาลานเซอร์, VPC flow log) แล้วนับว่าแต่ละประเทศและ ISP เชื่อมต่อไปรีเจียนไหน ถ้าเป็นผู้เล่นคนเดียว ให้เทียบรีเจียนที่ผู้เล่นคนนั้นเชื่อมต่อจริงกับปิงไปยังรีเจียนที่ใกล้ (ให้ผู้เล่นวัดเอง หรือ mtr จากเซิร์ฟเวอร์ในรีเจียนนั้นไปยัง IP ของผู้เล่น) สัญญาณว่าใช่ ผู้เล่นหรือประเทศที่ RTT สูงเชื่อมต่ออยู่กับรีเจียนไกลแทนรีเจียนใกล้ และปิงที่วัดไปยังรีเจียนใกล้ต่ำ สัญญาณว่าไม่ใช่ ถูกจัดไปรีเจียนใกล้ถูกต้องแล้วแต่ปิงยังสูง: น่าจะเป็นเส้นทางวิ่งอ้อม หรือเน็ต/Wi-Fi ของผู้เล่นคนนั้น วิธีตรวจ ใช้เครื่องมือฝั่งอินฟรา (ไม่ต้องใช้โค้ดเกม)
รายละเอียดเพิ่มเติม วิธีเลือกรีเจียนด้วย DNS (DNS ที่อิงตำแหน่งหรือความหน่วง) จะเดาตำแหน่งจากที่อยู่ของ DNS resolver ที่ผู้เล่นใช้แทนที่อยู่ของผู้เล่นเอง ถ้า resolver ไม่รองรับ EDNS Client Subnet ที่ส่งที่อยู่บางส่วนของผู้เล่นต่อไป ผู้เล่นที่ใช้ DNS ของบริษัทหรือ DNS ที่อยู่ไกลจะถูกจัดตามตำแหน่งของ resolver ระบบจับคู่เองก็อาจตัดสินปาร์ตี้จากค่าเฉลี่ยปิงของสมาชิก หรือขยายเกณฑ์ปิงเมื่อรอนานจนจัดไปรีเจียนไกล AWS GameLift Servers ก็ใช้ค่าเฉลี่ยเป็นเกณฑ์ปิงของปาร์ตี้โดยค่าเริ่มต้น และยกตัวอย่างการตั้งค่าที่ขยายเพดานปิงจาก 50 ms เป็น 100 ms และ 200 ms ผู้เล่นที่เปิด VPN อาจเจอทั้งดีเลย์ที่เพิ่มจากการผ่านเซิร์ฟเวอร์ตัวกลาง (“เชื่อมต่อผ่าน VPN/โปรแกรมลดปิง”) และการถูกจัดไปรีเจียนไกลซ้อนกัน จึงแยกได้จากการดูว่าเมื่อปิด VPN แล้วเชื่อมต่อใหม่ รีเจียนที่ถูกจัดให้เปลี่ยนหรือไม่ กรณีที่ไม่มีรีเจียนใกล้เลยจนต้องต่อไปรีเจียนไกล อธิบายไว้ใน “ความหน่วงในการแพร่สัญญาณ (ระยะทางจริง)”
แหล่งอ้างอิง RFC 7871: Client Subnet in DNS Queries IETF DNS ที่ตอบต่างกันตามตำแหน่งจะเดาตำแหน่งจากที่อยู่ของ resolver ที่ส่งคำถามมา และถ้าใช้ resolver ส่วนกลางที่อยู่ไกลจากผู้เล่น จะได้คำตอบที่ไม่เหมาะสม ส่งที่อยู่บางส่วนของผู้เล่นต่อไปด้วย EDNS Client Subnet (ฟีเจอร์ทางเลือก) How Amazon Route 53 uses EDNS0 to estimate the location of a user AWS ถ้า resolver ไม่รองรับ edns-client-subnet จะเดาตำแหน่งผู้เล่นจากที่อยู่ของ resolver และตอบตามตำแหน่งของ resolver (เหมือนกันทั้ง routing แบบอิงตำแหน่งและแบบอิงความหน่วง) Geolocation accuracy MaxMind ระดับประเทศประมาณ 99.8%, ระดับเมืองในสหรัฐฯ (ในรัศมี 50 กิโลเมตร) ประมาณ 66%, ถ้าใช้ VPN จะได้ตำแหน่งเซิร์ฟเวอร์ VPN แทนผู้ใช้ปลายทาง, IP ของเครือข่ายมือถือใช้กันในพื้นที่กว้างจึงระบุตำแหน่งละเอียดไม่ได้, ฐานข้อมูลต้องอัปเดตอย่างต่อเนื่อง, ขอแก้ไขข้อมูลได้ FlexMatch rule types AWS กฎความหน่วง (maxLatency) ดูความหน่วงของผู้เล่นแยกตามตำแหน่ง, ปาร์ตี้ใช้ค่าเฉลี่ยของสมาชิก (partyAggregation avg) เป็นค่าเริ่มต้น, คิวอาจวางไปรีเจียนที่ไม่ตรงกฎความหน่วงก็ได้ Create a player latency policy AWS วางไว้ในตำแหน่งที่ความหน่วงเฉลี่ยของผู้เล่นทุกคนต่ำที่สุด แต่ผู้เล่นที่ความหน่วงสูงแบบสุดโต่งก็ถูกวางด้วย, ตัวอย่างนโยบายที่ขยายเพดานปิงจาก 50 ms เป็น 100 ms และ 200 ms Amazon GameLift Servers UDP ping beacons AWS ไคลเอนต์เกมวัดความหน่วงด้วย UDP endpoint ที่มีในแต่ละตำแหน่งโฮสต์ แล้วใช้ในการวางเซิร์ฟเวอร์และจับคู่, ใกล้เคียงทราฟฟิกเกมจริงมากกว่า ICMP ping Azure network round-trip latency statistics Microsoft Azure ค่ามัธยฐานเวลาไปกลับที่วัดจริงจากโซล (Korea Central): โตเกียว (Japan East) 29 ms, สหรัฐฯ ฝั่งตะวันตก 124–136 ms Flow log records AWS srcaddr ใน record ของ VPC flow log: ถ้าเป็นทราฟฟิกขาเข้า คือ IP ของฝั่งผู้ส่ง สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L13 สถาปัตยกรรมเซิร์ฟเวอร์และการดูแลระบบ
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (อินพุตดีเลย์)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง