คู่มือเกมแลค › ค้นหาตามอาการ

กดไม่ติด/โรลแบ็ค: 36 สาเหตุและทีมที่ต้องแก้

เรียกอีกอย่างว่า: สกิลไม่ออก, ไอเทมย้อนกลับ, เทรดไม่สำเร็จ

เปิดพจนานุกรมอาการในฉบับหลักที่มีภาพ →

การกระทำที่ทำไปแล้วแน่ ๆ กลับไม่เกิดผล หรือผลถูกพลิกกลับหลังผ่านไปพักใหญ่

กดสกิลแล้วไม่ออก ไอเทมที่ซื้อหายไป หรือเข้าเกมใหม่แล้วกลับไปเป็นสถานะเมื่อหลายนาทีก่อน

คำขอหายไประหว่างทาง (แพ็กเก็ตหาย, คิวล้น), เซิร์ฟเวอร์ตัดสินต่างจากที่เห็นบนจอเรา (จังหวะเวลาตัดสินต่างกัน, เซิร์ฟเวอร์ปฏิเสธหลังแสดงผลล่วงหน้าไปแล้ว) หรือบันทึกล้มเหลวกลางทาง (DB ติดล็อกหรือล่ม, เซิร์ฟเวอร์แครช)

สาเหตุที่ทำให้เกิดอาการนี้

L1 โปรเซสเกมฝั่งไคลเอนต์

• ซิงก์นาฬิกาคลาดเคลื่อน: ถ้าเวลาเซิร์ฟเวอร์ที่ไคลเอนต์ประมาณไว้ผิด จังหวะ interpolation และการตัดสินคูลดาวน์จะคลาดกัน (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))

L5 อุปกรณ์เครือข่ายในดาต้าเซ็นเตอร์

• ขีดจำกัดการเชื่อมต่อ/พอร์ตของ NAT gateway บนคลาวด์: การเชื่อมต่อที่เซิร์ฟเวอร์ใน private subnet ออกไปภายนอก (ระบบยืนยันตัวตนของแพลตฟอร์ม, ระบบชำระเงิน, API ภายนอก) จะผ่าน NAT gateway ซึ่งแปลง IP และพอร์ตก่อนส่งออก ถ้าการเชื่อมต่อพร้อมกันไปยังปลายทางเดียวกันเกินขีดจำกัดพอร์ตของ gateway การเชื่อมต่อใหม่จะล้มเหลว (อินฟราเครือข่าย (ทีมอินฟรา))
• microburst ที่สวิตช์: ถ้าเซิร์ฟเวอร์หลายเครื่องส่งแพ็กเก็ตถึงผู้เล่นหลายพันคนพร้อมกันในชั่วขณะเดียว บัฟเฟอร์ขนาดเล็กของพอร์ตสวิตช์ที่ทราฟฟิกนั้นไหลมารวมกันจะล้นภายในไม่ถึง 1 ms (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

L6 การ์ดเครือข่ายของเซิร์ฟเวอร์

• ring buffer ไม่พอ: ถ้า ring buffer ที่ NIC ใช้พักแพ็กเก็ตไว้ชั่วคราวมีขนาดเล็ก เมื่อแพ็กเก็ตทะลักเข้ามาในชั่วขณะ บัฟเฟอร์จะล้นและแพ็กเก็ตถูกทิ้ง (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
• เกินขีดจำกัด PPS ของคลาวด์: เซิร์ฟเวอร์บนคลาวด์แต่ละประเภทมีขีดจำกัดจำนวนแพ็กเก็ตต่อวินาทีและแบนด์วิดท์ ถ้าเกินจะถูกทิ้งเงียบ ๆ (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))

L7 OS ของเซิร์ฟเวอร์ (เคอร์เนล)

• OOM killer: เมื่อหน่วยความจำหมด Linux จะเลือกโปรเซสที่ใช้หน่วยความจำมากที่สุดแล้วบังคับปิด ซึ่งส่วนใหญ่คือเซิร์ฟเวอร์เกม (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• นาฬิการะบบกระโดด (NTP step): ถ้านาฬิกาของเซิร์ฟเวอร์ถูกปรับไปข้างหน้าหรือถอยหลังหลายวินาทีในครั้งเดียว ตัวจับเวลาที่อิงนาฬิการะบบจะทำงานพร้อมกันรวดเดียวหรือหยุดไป (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• ephemeral port หมดในการเชื่อมต่อระหว่างเซิร์ฟเวอร์: ถ้าเซิร์ฟเวอร์เกมเปิดและปิดการเชื่อมต่อสั้น ๆ ไปยัง DB หรือเซิร์ฟเวอร์อื่นบ่อย ๆ การเชื่อมต่อที่ปิดแล้วจะยังถือครองพอร์ตอยู่สักพัก จนเปิดการเชื่อมต่อใหม่ไม่ได้ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

L8 ซ็อกเก็ตและโปรโตคอล

• การตั้งค่าการส่งซ้ำของ reliable UDP: ถ้ากฎการส่งซ้ำที่สร้างเองบน UDP ระมัดระวังเกินไป การกู้คืนจะช้า ถ้าดุดันเกินไปก็จะยิ่งทำให้เน็ตอุดตัน (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

L9 โปรเซสเกมฝั่งเซิร์ฟเวอร์

• ข้อความสะสมในคิว: ถ้าคำขอเข้ามาเร็วกว่าความเร็วในการประมวลผลจนกองในคิว คำขอที่อยู่ท้ายคิวจะถูกประมวลผลอีกหลายวินาทีต่อมาหรือถูกทิ้ง (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• เซิร์ฟเวอร์แครช: ถ้าโปรเซสเซิร์ฟเวอร์ตายเพราะข้อผิดพลาดที่ไม่ได้จัดการ ทุกคนในเซิร์ฟเวอร์นั้นจะหลุดพร้อมกัน (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• แพตช์ทำให้รูปแบบทราฟฟิกเปลี่ยน: ถ้าคอนเทนต์ เอฟเฟกต์ หรือรายการที่ต้องซิงก์ใหม่ทำให้ขนาดและความถี่ของแพ็กเก็ตเพิ่ม เซิร์ฟเวอร์ที่เคยลื่นจะเริ่มชนขีดจำกัด MTU แบนด์วิดท์ และจำนวนแพ็กเก็ตหลังลงแพตช์ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

L11 ดิสก์

• ดิสก์เต็ม: ถ้า log และ dump สะสมจนดิสก์เต็ม การเขียนจะล้มเหลว และถ้าไม่ได้เตรียมรับมือไว้ เซิร์ฟเวอร์จะล่ม (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))

L12 ฐานข้อมูล

• แย่งล็อกบน hot row: ถ้าทุกคนพยายามแก้แถวเดียวกัน (โกดังกิลด์, ไอเทมฮิตในตลาดประมูล, ตัวนับของทั้งเซิร์ฟเวอร์) จะได้ล็อกทีละคนเท่านั้น (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• เดดล็อกใน DB: ถ้าสองทรานแซกชัน (งาน DB ที่ประมวลผลเป็นชุดเดียว) ต่างรอแถวที่อีกฝ่ายล็อกไว้ DB จะบังคับยกเลิกฝั่งหนึ่ง (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• การทำสำเนาข้อมูลล่าช้า: การเขียนไปที่ DB หลัก ส่วนการอ่านทำจาก replica ถ้า replica ตามไม่ทัน ข้อมูลที่เพิ่งเขียนจะยังมองไม่เห็น (อินฟรา DB (ทีมอินฟรา))
• งาน batch ขนาดใหญ่: ถ้ารันการสรุปอันดับ, การส่งจดหมายในเกมแบบรวดเดียว หรือการล้างข้อมูลเก่าระหว่างให้บริการ งานเหล่านี้จะยึดล็อกและดิสก์ไว้ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• failover ของ DB: ระหว่างที่ DB หลักล่มและสลับไปใช้ DB สำรอง จะเขียนข้อมูลไม่ได้ และข้อมูลช่วงท้ายที่ยัง replicate ไม่ทันอาจหายไป (อินฟรา DB (ทีมอินฟรา))
• ความคืบหน้าหายเพราะรอบเซฟยาว: ถ้าเซฟแค่ทุกไม่กี่นาทีเพื่อลดโหลด เมื่อเซิร์ฟเวอร์ล่มในระหว่างนั้น ความคืบหน้าจะหายไป (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• ทรานแซกชันที่เปิดทิ้งไว้นาน: ถ้าทรานแซกชันหนึ่งเปิดทิ้งไว้นาน จะถือล็อกไว้ตลอด และ DB ล้างข้อมูลเวอร์ชันเก่า (purge) ไม่ได้ ทั้งระบบจึงค่อย ๆ ช้าลง (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• ล็อกจากการเปลี่ยนสคีมา (DDL) ระหว่างให้บริการ: ถ้าเพิ่มคอลัมน์หรืออินเด็กซ์ให้ตารางระหว่างให้บริการ ล็อกที่ต้องใช้เพียงชั่วครู่ตัวเดียวอาจทำให้ทุกคำขอที่ใช้ตารางนั้นต้องรอ (อินฟรา DB (ทีมอินฟรา))

L13 สถาปัตยกรรมเซิร์ฟเวอร์และการดูแลระบบ

• เซิร์ฟเวอร์เสริมขัดข้อง: ถ้าเซิร์ฟเวอร์ที่รันแยกจากเซิร์ฟเวอร์เกม เช่น แชต, ปาร์ตี้ หรือตลาดประมูล ขัดข้อง จะใช้งานไม่ได้เฉพาะฟีเจอร์นั้น (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• นาฬิการะหว่างเซิร์ฟเวอร์ไม่ตรงกัน: ถ้านาฬิกาของแต่ละเซิร์ฟเวอร์ต่างกันเล็กน้อย การตัดสินคูลดาวน์, บัฟ และเวลาเริ่มอีเวนต์จะไม่ตรงกันระหว่างเซิร์ฟเวอร์ (อินฟราเซิร์ฟเวอร์ (ทีมอินฟรา))
• การพึ่งพาเซอร์วิสภายนอก: ถ้าเซอร์วิสภายนอก เช่น ล็อกอินผ่านแพลตฟอร์ม, การชำระเงิน หรือการยืนยันตัวตน ช้าหรือหยุดทำงาน ผู้เล่นจะติดอยู่ที่ขั้นตอนนั้น (ภายนอก (ภายนอก))
• matchmaking/การจัดรีเจียนผิดพลาด: ถ้าถูกจัดไปเซิร์ฟเวอร์ในรีเจียนที่ไกลแทนรีเจียนที่ใกล้ ผู้เล่นคนนั้นจะปิงสูงตลอดแม้เน็ตจะปกติ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• ใบรับรอง TLS หมดอายุ/ตั้งค่าผิด: ถ้าใบรับรองของเซิร์ฟเวอร์ล็อกอิน, API หรือแพตช์หมดอายุ หรือขาดใบรับรองกลาง (intermediate certificate) ไคลเอนต์ที่เชื่อมต่อใหม่ตั้งแต่วินาทีนั้นจะเชื่อมต่อ TLS ไม่สำเร็จ (อินฟราเครือข่าย (ทีมอินฟรา))

การออกแบบการซิงก์

• ไม่มีการกดสกิลล่วงหน้า: ถ้าต้องได้การยืนยันจากเซิร์ฟเวอร์ว่าสกิลก่อนหน้าจบแล้วจึงจะกดสกิลถัดไปได้ ทุกคอมโบจะมีเวลาไปกลับแทรกเข้ามา (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
• ช่วงเวลาตัดสินสั้นจนปิงกินหมด: ถ้าเวลาที่ต้องตอบสนอง เช่น การหลบ, การแพร์รี และการกัน สั้นเกินไป ปิงจะกินเวลานั้นไปจนเกิดการโจมตีที่หลบไม่ได้ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• การตัดสินผลที่ไม่มี lag compensation: ถ้าเซิร์ฟเวอร์ตัดสินการโดนโดยดูแค่ “ตำแหน่งบนเซิร์ฟเวอร์ ณ ตอนนี้” ผลการตัดสินจะไม่ตรงกับที่เราเห็นบนจอ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• lag compensation มากเกินไป: ถ้าย้อนเวลาให้ผู้โจมตีไกลเกินไป ฝ่ายที่ถูกโจมตีจะโดนทั้งที่หลบไปแล้ว (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• client authoritative: ถ้าแต่ละคนตัดสินผลของตัวเอง จอของเราจะลื่น แต่ผลจะไม่ตรงกับจอของคนอื่นและโกงได้ง่าย (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• เซิร์ฟเวอร์ตรวจสอบเข้มงวดเกินไป: ถ้าเซิร์ฟเวอร์ตรวจความเร็วการเคลื่อนที่, คูลดาวน์ และระยะเข้มงวดเกินไป จะปฏิเสธแม้อินพุตปกติที่มาถึงรวมกันเพราะจิตเตอร์ (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• แสดงผลล่วงหน้าแล้วเซิร์ฟเวอร์ปฏิเสธ: ถ้าการโจมตีหรือสกิลที่จอเราแสดงไปก่อนแล้วถูกเซิร์ฟเวอร์ปฏิเสธทีหลัง ผลที่เห็นกับตาจะกลายเป็นเหมือนไม่เคยเกิดขึ้น (พัฒนาไคลเอนต์ (ทีมพัฒนาเกม))
• อัตราส่งสแนปช็อตต่ำ: ถ้าเซิร์ฟเวอร์ส่งอัปเดตตำแหน่ง (สแนปช็อต) แค่ไม่กี่ครั้งใน 1 วินาที ต้องตั้ง interpolation buffer ให้ยาวตามไปด้วย จึงเห็นตัวละครอื่นเป็นภาพในอดีตที่ไกลขึ้น (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

ปัญหาที่เกิดกับบางคนเท่านั้น

• false positive ของการตรวจสอบที่กระจุกกับผู้ใช้บาง ISP: คนที่ใช้เน็ตที่จิตเตอร์สูง อินพุตจะไปถึงเป็นกลุ่ม จึงติดการตรวจความเร็วและคูลดาวน์ของเซิร์ฟเวอร์บ่อย (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))
• เพื่อนในปาร์ตี้ที่ช้าหนึ่งคนกับกิมมิกบอส: ในกิมมิกเรดที่ทุกคนต้องตอบสนองพร้อมกันในจังหวะที่กำหนด การตอบสนองช้าของคนที่ช้าเพียงคนเดียวจะทำให้ทั้งปาร์ตี้ล้มเหลว (พัฒนาเซิร์ฟเวอร์ (ทีมพัฒนาเกม))

ดูพจนานุกรมอาการในฉบับหลักที่มีภาพ