บั๊ก `No user logon` ใน Steam ที่มีอายุ 10 ปี

 (blog.freudenjmp.com)
1 คะแนน โดย GN⁺ 2024-01-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ปัญหาการหลุดจากเกม No user logon ที่มีมานานใน Counter-Strike ยังเกิดซ้ำได้ใน CS2 และหากเชื่อมต่อเข้าเซิร์ฟเวอร์เร็วเกินไปทันทีหลังเริ่มเกม การตรวจสอบ Steam ID อาจไม่เริ่มทำงาน
  • ประเด็นสำคัญคือระหว่างที่ CS2.exe กำลังเริ่มทำงาน ลูป levelload อาจจบก่อนกำหนดก่อนที่การตรวจสอบ Steam3 จะเสร็จ และเซิร์ฟเวอร์จะจัดการการเชื่อมต่อด้วย Steam ID ที่ยังไม่ได้ตรวจสอบ
  • ในล็อกของ Esportal แม้แต่ผู้ใช้ปกติก็มีบันทึก STEAM USERID validated หลังเชื่อมต่อไปแล้วราว 1 นาที 20 วินาที ส่วนผู้ใช้ที่ล้มเหลวจะหลุดหลังผ่านไป 2–3 นาทีด้วย STEAMAUTH failure code 8 และ NETWORK_DISCONNECT_STEAM_LOGON
  • การติดตั้งเกมใหม่, ตรวจสอบไฟล์, รีสตาร์ต Steam, รีบูต PC, ปิด WiFi ไม่สามารถแก้ สาเหตุราก ได้ และควรเปิด CS2 ก่อนแล้วรอที่เมนูหลัก 5–10 วินาที
  • Esportal แก้พฤติกรรมที่เคยเรียก steam://connect/<IP>:<Port> ก่อนที่ CS2.exe จะ initialize เสร็จสมบูรณ์เมื่อวันที่ 10 มกราคม 2024 และหลังจากนั้นสัดส่วน ticket ที่เกี่ยวข้องลดลงเหลือ 0%

อาการ No user logon ที่เกิดซ้ำมายาวนาน

  • ปัญหาการหลุดจากเกม No user logon ของ Counter-Strike เป็นที่รู้กันว่าเกิดแบบสุ่มระหว่างเล่น และถูกแจ้งซ้ำ ๆ ในหลายฟอรัมรวมถึงฟอรัมซัพพอร์ตทางการของ Valve ตั้งแต่ปี 2008 ถึง 2023
  • No user logon และ No steam logon ที่พบในบางโพสต์ อาจเป็นชื่อคนละแบบของสาเหตุรากเดียวกันในเชิงเทคนิค
  • วิธีแก้ที่แพร่หลายในอินเทอร์เน็ตไม่สามารถแก้สาเหตุรากได้
    • ติดตั้งเกมใหม่
    • ตรวจสอบไฟล์เกม
    • รีสตาร์ต Steam
    • รีบูตคอมพิวเตอร์
    • ปิด WiFi
  • CS2 เข้ามาแทนที่ CS:GO เมื่อวันที่ 27 กันยายน 2023 และผู้ใช้ทั่วไปไม่สามารถเล่น CS:GO ได้อีกต่อไป
  • ขอบเขต bug bounty ของ Valve บน HackerOne ไม่รวม cs2.exe และรายงานเกี่ยวกับ CS2 Limited Test ก็ถูกระบุว่าอยู่นอกขอบเขตเช่นกัน

รายงานที่เพิ่มขึ้นอย่างฉับพลันบน Esportal

  • Esportal เคยเจอปัญหานี้ใน CS:GO มาก่อน โดยตามบันทึก การเกิดครั้งแรกคือ 2019-11-15 19:15:32 CET และครั้งสุดท้ายใน CS:GO คือ 2023-09-26 21:38:01 CET ซึ่งเป็นวันก่อนถูกแทนที่ด้วย CS2
  • ช่วงแรกของ CS2 ดูเหมือนปัญหาจะหายไป แต่รายงานจากผู้ใช้เพิ่มขึ้นในสัปดาห์แรกของเดือนมกราคม 2024
    • 2024-01-03: 6% ของ ticket รายวัน
    • 2024-01-05~06: 18%
    • 2024-01-07: 23%
    • 2024-01-08: 10%
    • 2024-01-09: 9%
  • ช่วงเวลาที่มีรายงานส่วนใหญ่กระจุกตัวอยู่ที่ 13–17 น. CET ซึ่งตรงกับ 04–08 น. ตามเวลา Washington ที่ Valve ตั้งอยู่
  • ก่อนหน้านี้รายงานกระจายค่อนข้างสม่ำเสมอตลอดทั้งวัน แต่ปัญหาที่สังเกตเห็นใหม่นี้กระจุกในช่วงเวลาเฉพาะ
  • ผู้เล่นนอก Esportal ก็เจอปัญหาเดียวกัน จึงไม่ใช่ปัญหาเฉพาะแพลตฟอร์มใดแพลตฟอร์มหนึ่ง

อาการ: การตรวจสอบ Steam ที่ล่าช้าและสกินที่หายไป

  • ข้อผิดพลาด No user logon ที่สังเกตพบเกิดขึ้นหลังผู้เล่นเชื่อมต่อเข้าเซิร์ฟเวอร์เกมแล้ว 2–3 นาที และช่วงเวลานี้ค่อนข้างคงที่
  • เพื่อนร่วมงานคนหนึ่งบอกว่า “หลังเข้าเกมแล้ว หลายนาทีแรกใน CS2 จะไม่เห็นสกิน” และผู้เล่นนอก Esportal ก็รายงานว่าสกินหายเช่นกัน
  • เนื่องจากสกินเชื่อมโยงกับความเป็นเจ้าของ Steam ID จึงเป็นไปได้ว่าก่อนที่สกินส่วนตัวจะแสดง ผู้เล่นยังไม่ได้รับการยืนยันตัวตนผ่าน Steam อย่างถูกต้อง
  • ในล็อกของผู้ใช้ปกติ มีบันทึก STEAM USERID validated หลังเชื่อมต่อไปแล้วราว 1 นาที 20 วินาที
16:39:55: "Alice<1><>" connected
16:41:14: "Alice<1><>" STEAM USERID validated
17:17:32: "Alice<1><CT>" disconnected (reason "NETWORK_DISCONNECT_DISCONNECT_BY_USER")
  • ในล็อกเก่าก่อนวันที่ 3 มกราคม 2024 การตรวจสอบ Steam เสร็จภายใน 2–3 วินาที หลังเชื่อมต่อ
  • สามารถจำลองปัญหาได้โดยตรงในช่วงกลางคืนของ Washington แต่จำลองไม่ได้ในช่วงกลางวันของ Washington

NETWORK_DISCONNECT_STEAM_LOGON และ failure code 8

  • ในล็อกของผู้ใช้ที่ล้มเหลว การเชื่อมต่อถูกตัดด้วย NETWORK_DISCONNECT_STEAM_LOGON ทันทีหลัง STEAMAUTH: Client Bob received failure code 8
16:40:13: "Bob<6><>" connected
16:43:02: STEAMAUTH: Client Bob received failure code 8
16:43:02: "Bob<6><TERRORIST>" disconnected (reason "NETWORK_DISCONNECT_STEAM_LOGON")
  • NETWORK_DISCONNECT_STEAM_LOGON น่าจะเป็น identifier ภายในของข้อความ No user logon ที่ผู้ใช้เห็น
  • มีการค้นหาสตริง STEAMAUTH: Client %s received failure code %d ใน libengine2.so และเปรียบเทียบร่วมกับ sv_steamauth.cpp จากซอร์ส CS:GO ที่รั่วไหลและผล reverse engineering
  • ฟังก์ชันที่เกี่ยวข้องของ CS2 จะตัดการเชื่อมต่อไคลเอนต์ตามค่า eAuthSessionResponse
    • 1: k_EAuthSessionResponseUserNotConnectedToSteam
    • 7: k_EAuthSessionResponseAuthTicketInvalidAlreadyUsed
    • 8: k_EAuthSessionResponseAuthTicketInvalid
  • failure code 8 ดูเหมือนจะตรงกับ k_EAuthSessionResponseAuthTicketInvalid ที่เห็นเมื่อการตรวจสอบ Steam3 ล้มเหลว

โฟลว์การตรวจสอบ Steam3

  • ไคลเอนต์เกม CS2.exe ส่ง Steam ID ของตัวเองเมื่อเชื่อมต่อเข้าเซิร์ฟเวอร์เกม
  • โครงสร้างคือเซิร์ฟเวอร์เกมจะถามเซิร์ฟเวอร์ Steam3 เพื่อตรวจสอบว่า Steam ID นั้นถูกต้องและเป็นเจ้าของเกมหรือไม่
  • ระหว่างรอคำตอบการตรวจสอบ ผู้เล่นยังสามารถเล่นต่อบนเซิร์ฟเวอร์ได้ แต่สกินส่วนตัวอาจไม่แสดง
  • หากเซิร์ฟเวอร์ Steam3 ส่ง “yes” กลับมา เซิร์ฟเวอร์เกมจะเชื่อถือข้อมูลนั้นและสามารถใช้ข้อมูลส่วนตัวอย่างสกินได้
  • หากเซิร์ฟเวอร์ Steam3 ส่ง “no” กลับมา เซิร์ฟเวอร์เกมจะตัดไคลเอนต์ด้วย NETWORK_DISCONNECT_STEAM_LOGON
  • ในสถานการณ์ที่การตอบสนองของ Steam3 ช้าช่วงกลางคืนของ Washington การตรวจสอบใช้เวลาราว 1 นาที 20 วินาที จึงเสร็จ

การตรวจสอบความน่าเชื่อถือของ CS2.exe และไคลเอนต์ Steam

  • การที่ Steam ID ถูกต้องเพียงอย่างเดียวไม่ได้พิสูจน์ว่าอินสแตนซ์ CS2.exe นั้นเป็นเกมของบัญชี Steam ที่ล็อกอินอยู่บนเครื่องเดียวกัน
  • CS2.exe ต้องเชื่อมต่อกับ Steam.exe บนเครื่องเดียวกัน เพื่อให้ตรวจสอบว่า Steam ID ที่ตัวเองส่งตรงกับบัญชี Steam ที่ล็อกอินอยู่ในขณะนั้น
  • เมื่อ Steam.exe ยืนยันว่าตรงกัน จะบันทึกข้อมูลชั่วคราวไว้ในเซิร์ฟเวอร์ Steam3 ว่า Steam ID นั้นถูกต้องสำหรับ CS2
  • ในบรรดาสาเหตุที่ Steam3 อาจตอบ “no” ตัวเลือกที่ใกล้กับปัญหาจริงถูกจำกัดเหลือสองข้อดังนี้
    • อินสแตนซ์ CS2.exe ไม่น่าเชื่อถือ
    • เซิร์ฟเวอร์ Steam3 ยังไม่รู้ข้อมูล Steam ID สำหรับอินสแตนซ์ CS2.exe นั้น

เบาะแสฝั่งไคลเอนต์: NETWORK_DISCONNECT_LOOPSHUTDOWN

  • ในล็อกที่ล้มเหลว มี NETWORK_DISCONNECT_LOOPSHUTDOWN ปรากฏก่อน NETWORK_DISCONNECT_STEAM_LOGON
16:40:03: "Bob<6><>" connected
16:40:08: "Bob<6><Unassigned>" disconnected (reason "NETWORK_DISCONNECT_LOOPSHUTDOWN")
16:40:13: "Bob<6><>" connected
16:43:02: STEAMAUTH: Client Bob received failure code 8
16:43:02: "Bob<6><TERRORIST>" disconnected (reason "NETWORK_DISCONNECT_STEAM_LOGON")
  • หลัง NETWORK_DISCONNECT_LOOPSHUTDOWN เกมจะพยายามเชื่อมต่อใหม่โดยอัตโนมัติหลังผ่านไป 5 วินาที
  • การหลุดครั้งแรกนี้ไม่ได้เริ่มโดยเซิร์ฟเวอร์เกม แต่เริ่มโดย CS2.exe เอง
  • ดังนั้นสาเหตุรากจึงอยู่ฝั่งไคลเอนต์เกม ไม่ใช่เซิร์ฟเวอร์เกม

ลูป levelload ของ Source 2 และลำดับการ initialize

  • เอนจิน Source 2 รัน active loop ได้ครั้งละหนึ่งลูป โดยลูปจะทำงานเบื้องหลังและประมวลผลอินพุตผู้ใช้ซ้ำ ๆ จนกว่าเป้าหมายเฉพาะจะเสร็จ
  • ลูปที่รันในท้ายที่สุดหลัง CS2.exe เริ่มทำงานคือ ลูป game ซึ่งรับผิดชอบการโต้ตอบกับเมนูจริงและ gameplay
  • ในเอาต์พุตคอนโซล สถานะการยืนยันตัวตน Steam แสดงเป็น OK ทันทีก่อนสลับไปลูป game
[SteamNetSockets] AuthStatus (steamid:<redacted>):  OK  (OK)
[Client] CL:  CLoopModeLevelLoad::MaybeSwitchToGameLoop switching to "game" loopmode with addons ()
[EngineServiceManager] SwitchToLoop game requested:  id [1] addons []
  • levelload เป็นลูป initialize ที่รันตอนเริ่ม CS2 และดูเหมือนจะโหลดหน้าจอเริ่มต้นอย่างวิดีโอ intro และเมนูหลัก แม้จะไม่ใช่แผนที่จริงก็ตาม
  • หนึ่งในงานสุดท้ายของ levelload คือการเริ่มการตรวจสอบ Steam3 จาก CS2.exe ผ่าน Steam.exe

สาเหตุโดยตรงของบั๊ก

  • CS2 จะถือว่า initialize เสร็จสมบูรณ์ได้ก็ต่อเมื่อลูป levelload จบลงสำเร็จแล้ว
  • หาก levelload ถูกจบก่อนกำหนดก่อนที่การ initialize จะเสร็จ การตรวจสอบ Steam3 จะไม่เริ่มทำงาน
  • อินสแตนซ์ CS2.exe ในสถานะนี้จะกลายเป็นสถานะเสีย และจะไม่ฟื้นกลับมาเพียงแค่ต้องเริ่ม CS2 ใหม่
  • โฟลว์ของบั๊กเป็นดังนี้
    • เริ่ม CS2.exe
    • เริ่มลูป levelload
    • levelload จบก่อนกำหนดก่อนเริ่มการตรวจสอบ Steam3
    • ลูป game เชื่อมต่อเข้าเซิร์ฟเวอร์เกมด้วย Steam ID ที่ยังไม่ได้ตรวจสอบ
    • เซิร์ฟเวอร์เกมตรวจสอบกับ Steam3
    • หลังสูงสุดราว 2 นาที 50 วินาที ได้รับคำตอบว่าล้มเหลวและตัดการเชื่อมต่อด้วย No user logon
  • แม้บทความนี้อธิบายโดยอิงตัวอย่างและชื่อของ CS2 แต่ CS:GO และ Counter-Strike: Source ก็มีบั๊กเทียบเท่ากัน โดยต่างกันเพียงชื่อเชิงเทคนิคและวิธีการ

วิธีเชื่อมต่อที่ทำให้เกิดบั๊ก

  • ปัญหานี้เป็น race condition ตามวิธีเริ่ม CS2
  • วิธีที่แทบจะทำให้เกิดบั๊กแน่นอนคือเชื่อมต่อเข้าเซิร์ฟเวอร์เกมทันทีในขณะที่ CS2 ยังไม่ได้เปิดอยู่
  • วิธีเชื่อมต่อที่เสี่ยงมีดังนี้
    • เชื่อมต่อเข้าเซิร์ฟเวอร์จาก server browser ภายนอกเกมในขณะที่ CS2 ยังไม่ได้รันหรือเพิ่งเริ่มรัน
    • เข้าร่วมเพื่อนจากรายชื่อเพื่อนใน Steam ในขณะที่ CS2 ยังไม่ได้รันหรือเพิ่งเริ่มรัน
    • เชื่อมต่อโดยตรงจากภายนอกด้วย Steam browser protocol เช่น steam://connect/127.0.0.1:27015
  • หากทำสิ่งข้างต้นหลังเริ่ม CS2 แต่ก่อน initialize เสร็จสมบูรณ์ โอกาสเกิดปัญหาจะสูงขึ้น
  • สัดส่วนสาเหตุถูกสรุปแบบเปรียบเปรยว่า “วิธีเริ่ม Counter-Strike 90%, ความเร็วคอมพิวเตอร์ 3%, ความเร็วผู้ใช้ 3%, สภาพดวงจันทร์ 3%, ปัญหาการตั้งค่าจริงของผู้ใช้ 1%”

วิธีแก้จริง

  • สิ่งที่ไม่ควรทำ
    • ติดตั้งเกมใหม่
    • ตรวจสอบไฟล์เกม
    • รีสตาร์ต Steam
    • รีบูตคอมพิวเตอร์
    • ปิด WiFi
    • เชื่อมต่อเข้าเซิร์ฟเวอร์เกมจากภายนอกก่อน CS2 เริ่มทำงาน
  • แทนที่จะทำเช่นนั้น ควรเปิด CS2 ก่อน แล้วรอให้เพียงพอก่อนเชื่อมต่อเข้าเซิร์ฟเวอร์เกม
  • เกณฑ์คือรอจนเห็นคอนโซลเกม หรือรอ 5–10 วินาที หลังเห็นวิดีโอ intro
  • หากต้องการตรวจสอบให้แน่ใจ ให้เริ่ม CS2 แล้วพิมพ์ status ในคอนโซลเกม จากนั้นตรวจสอบบรรทัดต่อไปนี้
[EngineServiceManager] @ Current  :  game

ผลลัพธ์จากการแก้ของ Esportal

  • เหตุผลที่ผู้ใช้ที่ล้มเหลว Bob ตรวจสอบสำเร็จหลังความพยายามแรก 9 นาที คือเขาเริ่ม CS2 ใหม่ และครั้งนั้นโชคไม่ร้ายจนเกิดบั๊ก
  • เมื่อ Steam ID ได้รับการตรวจสอบแล้ว ในอินสแตนซ์เกมเดียวกันจะไม่ล้มเหลวในภายหลังตราบใดที่ไม่ได้ปิดไคลเอนต์ Steam
  • จนถึงวันที่ 10 มกราคม 2024 Esportal เคยเชื่อมต่อผู้เล่นเข้า matchmaking server ด้วย steam://connect/<IP>:<Port> ทันทีที่โปรเซส CS2.exe ถูกสร้างขึ้น แม้ยังไม่ initialize เสร็จสมบูรณ์
  • เมื่อแก้พฤติกรรมนั้นและ deploy ให้ผู้เล่น Esportal ทุกคนแล้ว ticket ผู้ใช้ที่เกี่ยวข้องก็หยุดลง
  • สัดส่วน No user logon ใน ticket รายวันเคยขึ้นถึง 23% เมื่อ 2024-01-07 แต่ลดลงเป็น 0% ตั้งแต่ 2024-01-10 ถึง 2024-01-12

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-01-14
ความคิดเห็นใน Hacker News

  • โฟลว์ในไดอะแกรมใกล้เคียงกับสิ่งที่ Steam เรียกว่า Session Tickets มากกว่า และในความเป็นจริงมีรายละเอียดปลีกย่อยกว่านั้นเล็กน้อย
    หลังจากไคลเอนต์เกมขอ session ticket จากเซิร์ฟเวอร์ Steam แล้ว ก็จะส่ง ticket ให้เซิร์ฟเวอร์เกมเพื่อพิสูจน์ว่าตนเป็น Steam ID นั้นจริง
    จากนั้นเซิร์ฟเวอร์เกมต้องตรวจสอบออนไลน์กับ Web API ของ Steam ว่า ticket ไม่ได้ถูกใช้ซ้ำหลายครั้งหรือถูกดัดแปลง
    ฟังดูเหมือนว่าไคลเอนต์ CS2 จัดการ การตอบสนองที่ล่าช้า ในกระบวนการขอ session ticket ได้ไม่ถูกต้อง
    โฟลว์อธิบายไว้ละเอียดที่นี่: https://partner.steamgames.com/doc/features/auth#3
    ถ้ามันทำงานเหมือนไดอะแกรมในบทความจริง ก็ค่อนข้างน่ากังวล เพราะผู้โจมตีอาจแข่งเข้าร่วมเซิร์ฟเวอร์ด้วย Steam ID ของเหยื่อได้

    • ใช่ โดยรวมแล้วมีความเป็นไปได้สูงว่าเป็น session ticket และดูเหมือนบทความจะไม่ได้อธิบายส่วนนั้นให้ชัดเจน
      ปัญหาน่าจะอยู่ตรงที่เกมถูกขัดจังหวะก่อนจะสร้าง session ticket จริง ๆ หรือระหว่างรอการตอบสนองที่ช้าจากเซิร์ฟเวอร์ Steam แล้วไปเชื่อมต่อกับเซิร์ฟเวอร์เกมโดยไม่มี ticket
    • ใช่ ในเชิงเทคนิคโฟลว์นี้ถูกต้อง และผมมองว่าไม่สำคัญมากต่อคำอธิบายปัญหา แต่ก็ควรกล่าวให้ชัดเจนกว่านี้

  • บทความดีมาก แต่กระบวนการสืบตามปัญหากับข้อสรุปไม่ได้สอดคล้องกันทั้งหมด
    แม้จะบอกว่า “วิธีที่ Counter-Strike เริ่มต้นขึ้น: สัดส่วนความรับผิดชอบ 90%” แต่ส่วนที่บอกว่าผู้เล่นทั่วโลกก็เจอปัญหาเดียวกันนอก Esportal และยืนยันว่าเกิดจากการบำรุงรักษาตอนเที่ยงคืนในวอชิงตันนั้น ยากที่จะเป็นจริงพร้อมกันได้
    ถ้าความรับผิดชอบ 90% อยู่ที่วิธีการรันเกม ปัญหาก็คงไม่ได้กระจุกตามช่วงเวลาบำรุงรักษา
    ประเด็นหลักดูเหมือนจะอยู่ที่ “การตรวจสอบ Steam ID เริ่มขึ้นทันทีก่อนที่ game loop จะเริ่ม” และ “ถ้าการเริ่มต้น levelload ยังไม่เสร็จ การตรวจสอบ Steam3 ซึ่งเป็นขั้นตอนสุดท้ายก็จะยังไม่เริ่ม”
    กล่าวคือ ถ้า เซิร์ฟเวอร์ steam3 ช้ามากในช่วงบำรุงรักษา กระบวนการนี้จะยืดออกไป และระหว่างนั้นโอกาสที่จะเริ่มเกมแล้วตัด loop ก็จะสูงขึ้น
    ดังนั้น “วิธีที่ Counter-Strike เริ่มต้นขึ้น” ก็ถูก แต่ถ้อยคำอย่าง “สถานะของดวงจันทร์: สัดส่วนความรับผิดชอบ 3%” โดยแท้จริงแล้วชี้ไปที่ช่วงเวลาบำรุงรักษา จึงออกจะคลาดเคลื่อนเล็กน้อย
    คำแนะนำควรรวมไว้ด้วยว่า “ช่วง 13:00–17:00 CET เป็นช่วงบำรุงรักษาของ Valve ให้รอเพิ่มอีกสองสามนาที”
    อย่างไรก็ดี ผมเคยเจอปัญหานี้เอง และวิธีแก้ “รอสักหน่อยให้โหลดเสร็จ” เป็นวิธีที่ใช้งานได้จริงและสมเหตุสมผลที่สุดเท่าที่เคยได้ยินมา

    • รายละเอียดของคำอธิบายหรือข้อสรุปมีช่องโหว่อยู่บ้าง แต่ก็ยากจะมั่นใจว่าการตีความนี้ถูกต้องทั้งหมดเช่นกัน
      ใน CS:GO ก็เคยมีปัญหาเดียวกันโดยไม่เกี่ยวกับช่วงบำรุงรักษา ส่วนใน CS2 สังเกตพบเฉพาะช่วงบำรุงรักษาเท่านั้น
      สุดท้ายแล้ว ลักษณะบั๊กใน CS:GO กับ CS2 อาจแตกต่างกันก็ได้ แต่เมื่อ CS:GO ถูกแทนที่ด้วย CS2 แล้ว ก็ไม่มีทางพิสูจน์ได้อีก

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

    • ลองทำดูได้ไหม? :D

  • บั๊กจริง ๆ คือการยืนยันตัวตนสำเร็จไม่ได้เป็น เงื่อนไขบังคับสำหรับการเริ่มเล่นมัลติเพลเยอร์ที่ไม่ใช่ LAN

    • หรืออีกปัญหาคือโฟลว์การตรวจสอบ session ticket พึ่งพาการเชื่อมต่อระหว่างเซิร์ฟเวอร์เกมกับเซิร์ฟเวอร์ยืนยันตัวตนของ Valve ซึ่งดูเหมือนว่าเซิร์ฟเวอร์ยืนยันตัวตนนั้นบางครั้งช้ามาก
      วิธีที่เร็วและทนทานกว่าน่าจะเป็นให้ไคลเอนต์ Steam รับ โทเคนที่มีลายเซ็น อายุใช้งานไม่กี่ชั่วโมงจาก Valve มาเก็บไว้ แล้วส่งโทเคนนั้นทุกครั้งที่เชื่อมต่อกับเซิร์ฟเวอร์เกม
      เซิร์ฟเวอร์เกมก็ตรวจสอบในเครื่องด้วยใบรับรองสาธารณะที่ Valve ออกให้และแจกจ่ายมาพร้อมคอนเทนต์ของเซิร์ฟเวอร์ได้

  • บางย่อหน้าให้ความรู้สึกเหมือน “วางหมวกซ้อนบนหมวกอีกใบ”
    คือซ้อนความประชดประชันเพิ่มบนย่อหน้าที่เป็นมีมอยู่แล้ว ทำให้องค์ประกอบที่มักได้ผลดีกว่าเมื่อใช้อย่างแยบยลรู้สึกว่า มากเกินไป
    อย่างที่คนอื่น ๆ บอก ควรเข้าสู่ประเด็นหลักให้เร็วกว่านี้

  • อ่านสนุกมาก สงสัยว่าจะสืบหาสาเหตุที่ไคลเอนต์เกมแครชกะทันหันด้วยวิธีเดียวกันได้ไหม
    สงสัยด้วยว่า การตรวจสอบความสมบูรณ์ของไฟล์ ยังทำงานระหว่างที่เกมรันอยู่หรือเปล่า และถ้าหนึ่งในนั้นล้มเหลวระหว่างรัน จะมีข้อความตัดการเชื่อมต่อแบบอื่นขึ้นมาหรือไม่
    ดูเหมือนเป็นงานที่สมควรได้รับรางวัล เหมือนบทความวิเคราะห์ปัญหาเวลาโหลด GTA V ที่นานเกินไป: https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...

    • อยากรู้ว่าหมายถึงแครชกะทันหันแบบไหน
      โดยทฤษฎีแล้วแครชสามารถสืบวิเคราะห์ได้ แต่ Valve ไม่ได้บันทึกรายงานแครชลงดิสก์ แต่ส่งไปยังเซิร์ฟเวอร์
      ถ้าไม่ได้จับแบบเรียลไทม์โดยแนบดีบักเกอร์ไว้ การวิเคราะห์จะยากขึ้น และเพราะ VAC ก็เลยยุ่งยาก แต่ไม่ใช่ว่าทำไม่ได้ แค่ปิด VAC ก็พอ

  • การวางสรุปสำหรับคนที่ค้นหาวิธีแก้ปัญหาเข้ามาไว้ตอนต้นบทความถือว่าใส่ใจดี
    แต่จากนั้นกลับพูดต่อทันทีว่า “สิ่งที่ไม่ควรทำ” และสิ่งที่ทำได้จริงกลับถูกซ่อนไว้ในประโยคหนึ่งกลางบทความยาวระดับกิโลเมตร
    ควรใส่ วิธีเลี่ยงปัญหา ไว้ในสรุปด้วย

    • แทบจะเหมือนมุกตลกร้ายเลย สรุป: อย่าทำสิ่งนี้ แล้วไปอ่านบทความทั้งฉบับแทน!
    • “บทความยาวระดับกิโลเมตร” ถ้านับเป็นหน่วยคำนวณก็ประมาณกด Page Down 25 ครั้ง ถ้าเป็นหน่วยเสรีก็ประมาณ CTRL+F
    • พูดถูก เลยแก้เป็นสรุปที่ดีกว่าแล้ว

  • ที่พูดนี่เพราะรสนิยมการเขียนแบบ Strunk and White ฝังอยู่ในหัว จะมองข้ามก็ได้ถ้าต้องการ
    ถ้าต้องการฟีดแบ็ก ผมแนะนำให้ แก้ไขอย่างหนัก ให้บทความตรงประเด็นและกระชับกว่านี้มาก
    เขียนยาวได้ แต่พอผ่านไปไม่กี่นาที คำอธิบายเสริมและเกร็ดเล่าเรื่องก็สะสมจนผมหลุดจากเส้นเรื่องหลักค่อนข้างเร็ว
    ยิ่งใส่ภาพอ้างอิง Inception เข้ามาด้วย ก็ยิ่งให้ความรู้สึกว่าเป็นการรวมสิ่งที่ไม่ค่อยเกี่ยวข้องกัน มากกว่าจะเป็นบทความถ่ายทอดข้อมูล
    คิดให้ชัดว่าต้องการพูดอะไร พูดสิ่งนั้น แล้วกลับมาตรวจอีกครั้งว่าพูดแค่สิ่งนั้นจริงหรือไม่
    ที่เหลือไม่ใช่งานเขียน แต่ใกล้เคียงกับการฝึกพิมพ์มากกว่า ถ้ามีเรื่องจะพูด 3–4 เรื่อง ก็พูดแค่นั้นก็พอ

  • บทความยอดเยี่ยม แต่ยังมีคำถามอยู่สองสามข้อ
    levelloadloop รันเฉพาะตอนเปิดเกมเท่านั้น และไม่รันตอนเข้าร่วมเซิร์ฟเวอร์กับตอนโหลดแผนที่หรือไม่?
    ถ้าปัญหาคือ loop จบก่อนที่กระบวนการยืนยันตัวตนกับ Steam จะเริ่ม แล้วเหตุใดอาการช้าจากการบำรุงรักษาจึงสำคัญ?

    • ข้อ 1 ถูกต้อง รันเฉพาะตอนเปิดเกมเท่านั้น
      ชื่อ loop นี้ดูเกี่ยวข้องกับเกมผู้เล่นคนเดียวอย่าง Portal และในเกมแบบนั้นมีการเปลี่ยนด่านอย่างไร้รอยต่อ ชื่อนี้จึงฟังดูเป็นธรรมชาติกว่ามาก
      ข้อ 2 เป็นช่องโหว่ในคำอธิบายจริง และผมไม่รู้คำตอบ
      แต่อย่างน้อยก็แน่ชัดว่าวิธีนี้แก้ปัญหาได้ รายละเอียดของข้อสรุปมีแนวโน้มจะไม่สมบูรณ์ แต่ตอนนี้ผมไม่รู้สึกว่าจำเป็นต้องขุดลึกกว่านี้

  • ถ้อยคำในโปรแกรมให้รางวัลของ Valve ระบุว่าครอบคลุม “แพลตฟอร์ม Steam และเกมปัจจุบันที่ Valve พัฒนาและเผยแพร่”
    อีกทั้งยังระบุว่าตั้งแต่ 14 มิถุนายน 2023 เวลา 10:00 น. PDT รายงานใหม่เกี่ยวกับ CS:GO อยู่นอกขอบเขต และรายงานเกี่ยวกับ CS2 Limited Test ก็อยู่นอกขอบเขตในปัจจุบันเช่นกัน
    จริงอยู่ว่า Valve อ่อนด้านความปลอดภัย แต่ถ้าอ่านคำอธิบาย HackerOne ทั้งหมดแบบกว้าง ๆ โดยส่วนตัวผมจะถือว่าอยู่ ในขอบเขต
    หมายความว่าในแท็บ “Scope” ไม่ได้อัปเดตให้ยกเว้น csgo.exe จึงยากจะเชื่อถือเฉพาะแท็บนั้น
    ถึงอย่างนั้น Valve ก็ควรอัปเดตส่วนนั้นเสียที

    • Valve ไม่ตอบแม้แต่คำขอธรรมดา ๆ ที่ถามว่าสิ่งนี้อยู่ในขอบเขตหรือไม่ จึงไม่มีทางรู้ได้
      แต่ผมเห็นด้วยกับข้อสรุป และมันก็สมเหตุสมผล