รับทราบความน่าเชื่อถือโดยใช้ UDP

ฉันมีคำถามเกี่ยวกับ UDP สำหรับบริบทฉันทำงานในเกมแอ็คชั่นตามเวลาจริง

ฉันได้อ่านบ้างเล็กน้อยเกี่ยวกับความแตกต่างระหว่าง UDP และ TCP และฉันรู้สึกว่าเข้าใจค่อนข้างดี แต่มีชิ้นส่วนหนึ่งที่ไม่เคยรู้สึกถูกต้องและน่าเชื่อถือและมีการตอบรับเป็นพิเศษ ฉันเข้าใจว่า UDP ไม่ได้ให้ความน่าเชื่อถือตามค่าเริ่มต้น (เช่นแพ็คเก็ตสามารถถูกทิ้ง เมื่อจำเป็นต้องมีความน่าเชื่อถือโซลูชันที่ฉันเห็น (ซึ่งเหมาะสมตามแนวคิด) คือการใช้ acceptgments (เช่นเซิร์ฟเวอร์ส่งแพ็กเก็ตไปยังไคลเอ็นต์และเมื่อไคลเอ็นต์ได้รับข้อความนั้นจะส่งการตอบกลับไปยังเซิร์ฟเวอร์) .

จะเกิดอะไรขึ้นเมื่อการตอบรับลดลง

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

อย่างไรก็ตามหากลูกค้าส่งการตอบรับที่ไม่เคยมาถึงเซิร์ฟเวอร์จะไม่มีทางเลือกนอกจากต้องหยุดส่งข้อความในที่สุดซึ่งอาจทำลายเกมได้หากจำเป็นต้องมีข้อมูลในแพ็คเก็ตนั้น คุณสามารถใช้วิธีการที่คล้ายกันไปยังเซิร์ฟเวอร์ (เช่นส่งการตอบรับจนกว่าคุณจะได้รับ ack สำหรับ ack?) แต่วิธีการนั้นจะทำให้คุณวนกลับไปกลับมาตลอดไป (เนื่องจากคุณต้องการ ack สำหรับ ack สำหรับ ack และอื่น ๆ )

ฉันรู้สึกว่าตรรกะพื้นฐานของฉันถูกต้องตรงนี้ซึ่งทำให้ฉันมีสองตัวเลือก

1. ส่งแพ็คเก็ตการตอบรับเพียงครั้งเดียวและหวังว่าจะดีที่สุด
2. ส่งแพ็คเก็ตการรับทราบจำนวนหนึ่ง (อาจ 3-4) และหวังว่าจะดีที่สุดโดยสมมติว่าจะไม่ทิ้งทั้งหมด

มีคำตอบสำหรับปัญหานี้หรือไม่? ฉันเข้าใจอะไรผิดหรือเปล่า? มีการรับประกันการใช้ UDP บางอย่างที่ฉันไม่ทราบหรือไม่? ฉันลังเลที่จะก้าวไปข้างหน้าด้วยรหัสเครือข่ายมากเกินไปจนกว่าฉันจะรู้สึกสะดวกสบายที่ตรรกะของฉันเป็นเสียง

นี่เป็นรูปแบบของปัญหานายพลสองคนและคุณถูกต้อง - ไม่มีการลองซ้ำจำนวนมากพอที่จะรับประกันการรับได้อย่างสมบูรณ์แบบ

ในการฝึกซ้อมในเกมมักจะมีระยะเวลาเกินกว่าที่ข้อมูลจะไม่สำคัญแม้ว่าจะมีเทคนิคมาถึงแล้วก็ตาม เช่นเดียวกับการค้นพบว่าคุณมีภาพหัวที่สมบูรณ์แบบเมื่อ 2 วินาทีก่อน - มันสายเกินไปที่ผู้เล่นจะใช้ข้อมูลนั้นในตอนนี้

หากการสูญเสียแพ็กเก็ตของคุณสูงมากจนคุณไม่สามารถรับข้อมูลที่ต้องการเป็นประจำได้จากภายในหน้าต่างตอบโต้ที่เข้มงวดจากนั้นสำหรับเกมเรียลไทม์คุณอาจจะดีกว่าที่จะเตะผู้เล่นและพยายามหาคู่ที่เหมาะสมกว่า พยายามส่งแพ็กเก็ตต่อไปเพื่อจำลองการเชื่อมต่อที่เชื่อถือได้

ด้วยเหตุนี้ระบบการจำลองแบบเกมบางเกมจึงข้ามการตอบรับ & ลองใหม่ทั้งหมดและเลือกที่จะสแปมการอัพเดทล่าสุดบ่อยเท่าที่จะทำได้ หากมีใครตกหรือมาสายไม่ดีข้ามไปรับคนต่อไปแล้วใช้ระบบทำนายและแก้ไขเพื่อทำให้ช่องว่างราบรื่นและลดอาการสะอึกที่มองเห็นได้

ทันใดนั้นฉันต้องการเริ่มเรียกสิ่งนี้ว่า "การจำลองแบบ Simba" โดยไม่สนใจปัญหาในอดีตและพยายามที่จะอยู่ในช่วงเวลาปัจจุบัน ;)

โซลูชันไฮบริดคือการแข่งล่วงหน้าส่งอัปเดตใหม่และ (เนื่องจากการอัปเดตสถานะของเกมมักจะมีขนาดค่อนข้างเล็ก / บีบอัดได้ ) ยังมีการแพ็คอัปเดตครั้งล่าสุดและอาจเป็นหนึ่งก่อนหน้านั้น ... ดังนั้นในกรณีที่ลูกค้าพลาด คุณไม่ต้องรอเวลาไปกลับเพื่อหาและแก้ไข เวลาส่วนใหญ่ที่ไคลเอ็นต์เห็นสิ่งนี้ดังนั้นจึงมีข้อมูลซ้ำซ้อนในลักษณะนี้ แต่เวลาแฝงสำหรับการแก้ไขข้อความที่พลาดนั้นต่ำกว่า การอัปเดตของลูกค้าสามารถรวมหมายเลขดัชนีของการอัปเดตที่ต่อเนื่องล่าสุดที่พวกเขาได้เห็นดังนั้นคุณสามารถระมัดระวังน้อยที่สุดว่ามีการอัปเดตเก่า ๆ กี่ครั้งที่คุณรวมอยู่ในแพ็กเก็ตการอัพเดทครั้งต่อไป

นอกจากนี้คุณยังสามารถใช้ระบบสองระดับเป็นไฮบริดชนิดอื่นซึ่งสถานะแบบสั้น ๆ ถูกทำซ้ำในลักษณะที่รวดเร็วไม่น่าเชื่อถือและสถานะระยะยาวจะถูกซิงโครไนซ์อย่างน่าเชื่อถือโดยใช้ TCP หรือความน่าเชื่อถือของคุณเอง นับ. สิ่งนี้มีความซับซ้อนมากขึ้นในการจัดการเนื่องจากคุณมีระบบการส่งข้อความสองระบบที่ต้องดูแลรักษาและสแนปชอตสองรายการอาจไม่ซิงค์กันอีกทั้งยังเพิ่มเคสขอบใหม่ทั้งหมด

วิธีการที่ TCP ใช้คือผู้ส่งจะส่งแพ็กเก็ตอีกครั้งจนกว่าจะได้รับการตอบรับ ผู้รับจะไม่สนใจแพ็กเก็ตที่ซ้ำกัน แต่ยังคงส่งการตอบรับสำหรับพวกเขา ผู้ส่งจะเพิกเฉยการตอบรับซ้ำซ้อน

หากแพ็กเก็ตสูญหายผู้ส่งจะส่งซ้ำตามที่คุณรู้อยู่แล้ว
หากการตอบรับสูญหายผู้ส่งจะส่งแพ็กเก็ตดั้งเดิมซึ่งทำให้ผู้รับรับส่งการตอบรับอีกครั้ง

หากไม่ได้รับการตอบรับภายในเวลาที่กำหนด (อาจเป็น 60 วินาทีหรือลองอีก 20 ครั้ง) ผู้เล่นจะถูกตัดการเชื่อมต่อจากเกม คุณต้องใช้กฎการหมดเวลาบางอย่างมิฉะนั้นผู้เล่นที่ถอดสายเคเบิลเครือข่ายจะผูกทรัพยากรบนเซิร์ฟเวอร์ของคุณตลอดไป

หากคุณต้องการบูรณาการ TCP อีกครั้งคุณควรดูที่ TCPก่อนซึ่งเกี่ยวข้องกับปัญหาที่แน่นอนที่คุณอธิบาย

โซลูชันที่ใช้ 2 ช่องสัญญาณช่อง TCP (สำหรับการสื่อสารที่เชื่อถือได้) เช่นเดียวกับช่องสัญญาณ UDP (สำหรับการสื่อสารที่มีความหน่วงต่ำ) ไม่ใช่เรื่องแปลก

วิธีแก้ปัญหาบางอย่างตรวจพบเมื่อไคลเอนต์ขาดข้อมูลบางส่วนนานเกินไปและเริ่มการซิงโครไนซ์ใหม่ซึ่งอาจใช้ UDP หรือ TCP

วิธีการทั่วไปอีกวิธีหนึ่งคือการออกแบบการสื่อสารโดยที่ไม่ต้องพึ่งพาการตอบรับทั้งหมด แต่มันอยู่นอกขอบเขตของคำถาม

ใน RTS คุณไม่สามารถใช้โปรโตคอลเช่น TCP และคุณไม่สามารถทำให้ UDP เชื่อถือได้ หากคุณพยายามที่จะเกมจะหยุดเมื่อใดก็ตามที่มีเครือข่าย hick-up

แต่คุณออกแบบโปรโตคอลเพื่อให้แพ็กเก็ตที่ไม่ได้รับมีความสำคัญมาก

เวอร์ชั่นสั้นคือคุณไม่สนใจว่าผู้เล่นคนอื่นอยู่ที่เฟรมสุดท้ายตราบเท่าที่คุณรู้ว่าตอนนี้พวกเขาอยู่ที่ไหน รุ่นยาวซับซ้อนกว่า

คำถามก็จะกลายเป็นว่าคุณจะทำอย่างไรเมื่อแพ็กเก็ตหายไป? และคำตอบคือ ... คุณเดา ผู้เล่นอาจเคลื่อนที่เป็นเส้นตรงใช่ไหม? เพียงแค่เลื่อนพวกมันไปอีกขั้นหนึ่งตามแนวนั้น ... ยกเว้นผู้เล่น RTS ที่ไม่เคยเคลื่อนไหวเป็นเส้นตรง แล้วมีการตรวจจับการชนกันของ

นี่มันยาก. มีหลายเกมที่คิดผิด อาจเป็นที่ถกเถียงกันอยู่ว่าไม่มีคำตอบที่ถูกต้องในเรื่องนี้เฉพาะความผิดที่หลากหลายที่สามารถทำการค้าขายได้

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