คู่มือเกมแลค › L8 ซ็อกเก็ตและโปรโตคอล
การตั้งค่าการส่งซ้ำของ reliable UDP Reliable-UDP tuning (KCP, ENet…)
ID สาเหตุ sk-reliable-udp · ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ พัฒนาไคลเอนต์ (ทีมพัฒนาเกม)
เปิดการ์ดในฉบับหลักที่มีภาพและการทดลอง →
ถ้ากฎการส่งซ้ำที่สร้างเองบน UDP ระมัดระวังเกินไป การกู้คืนจะช้า ถ้าดุดันเกินไปก็จะยิ่งทำให้เน็ตอุดตัน
ทำไม ช่วงห่าง จำนวนครั้ง และขนาด window ของการส่งซ้ำไม่เหมาะกับเน็ต → ผลคือ กู้คืนช้า หรือส่งซ้ำซ้อนจนความแออัดแย่ลง → บนหน้าจอ สกิลไม่ออก, กรอเร็ว, แลคหนักขึ้นตอนเครือข่ายแออัด
- อาการ
- กดไม่ติด/โรลแบ็ค, กรอเร็ว
- ปัจจัย
- แพ็กเก็ตหาย, ความหน่วง
- ใครเจอ
- เราคนเดียว
- เกิดเมื่อไร
- สุ่มเป็นครั้งคราว
- ผู้รับผิดชอบ
- ผู้รับผิดชอบหลัก พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม) · ร่วมกับ พัฒนาไคลเอนต์ (ทีมพัฒนาเกม)
- งานฝั่งทีมพัฒนาเกม
- เซิร์ฟเวอร์: ส่งซ้ำตามเวลาไปกลับที่วัดได้, แยกช่องทางตามความสำคัญ ไคลเอนต์: ใช้การตั้งค่าการส่งซ้ำและช่องทางเดียวกับเซิร์ฟเวอร์
- บนกราฟ
- พุ่งแบบสุ่มเป็นครั้งคราว · อัตราการส่งซ้ำของ reliable UDP, RTT ในเกม
- จุดที่ต้องดู
- สถิติต่อการเชื่อมต่อของไลบรารีที่ใช้ (จำนวนการส่งซ้ำ, เวลาไปกลับที่ประมาณ, เวลารอก่อนส่งซ้ำ) บันทึกทั้งฝั่งเซิร์ฟเวอร์และไคลเอนต์ แล้วเทียบกับอัตราแพ็กเก็ตหายจริงบนเน็ตของผู้เล่นคนเดียวกัน (ค่าที่วัดด้วย mtr)
- สัญญาณว่าใช่
- อัตราการส่งซ้ำสูงกว่าอัตราแพ็กเก็ตหายจริงหลายเท่า: ตั้งค่าดุดันเกินไป เวลารอก่อนส่งซ้ำนานเป็นหลายเท่าของเวลาไปกลับที่วัดได้: ตั้งค่าระมัดระวังเกินไป
- สัญญาณว่าไม่ใช่
- อัตราการส่งซ้ำใกล้เคียงอัตราแพ็กเก็ตหาย และเวลารอสอดคล้องกับเวลาไปกลับ: ไม่ใช่ปัญหาการตั้งค่า ให้ดูแพ็กเก็ตหายบนเน็ตโดยตรง
- วิธีตรวจ
- ต้องมี log หรือเมตริกจากเซิร์ฟเวอร์/ไคลเอนต์เกม
แหล่งอ้างอิง
- RFC 8085: UDP Usage Guidelines IETF
การส่งซ้ำอาจเพิ่มความแออัดจึงต้องอยู่ภายใต้ congestion control, ประมาณเวลาไปกลับจากค่าเฉลี่ยของการวัดหลายครั้ง (EWMA), ค่าเริ่มต้น 1 วินาที, ลดอัตราการส่งเมื่อตัวจับเวลาหมดเวลา
สาเหตุที่ควรดูประกอบ
ชั้นเดียวกัน: L8 ซ็อกเก็ตและโปรโตคอล
สาเหตุจากชั้นอื่นที่ทำให้เกิดอาการเดียวกัน (กดไม่ติด/โรลแบ็ค)
ดูการ์ดในฉบับหลักที่มีภาพและการทดลอง