มันสมเหตุสมผลไหมที่จะใช้ทั้ง TCP และ UDP ในครั้งเดียว?

หลังจากอ่านUDP ยังดีกว่า TCP สำหรับเกมเรียลไทม์ที่มีข้อมูลมากหรือไม่? ฉันสงสัยว่ามันสมเหตุสมผลที่จะใช้ทั้ง TCP และ UDP ในเวลาเดียวกัน แต่สำหรับสิ่งต่าง ๆ :

• TCP สำหรับการส่งข้อมูลที่ส่งไม่บ่อยนัก แต่ควรรับประกันว่าจะมาถึงอย่างน่าเชื่อถือ
  เช่นการอัพเดทคะแนนชื่อของผู้เล่นหรือแม้แต่สถานะเปิด / ปิดของแสงในโลกของเกม

• UDP สำหรับการส่งข้อมูลที่อัปเดตอยู่ตลอดเวลาและอาจสูญหายได้ในบางครั้งเนื่องจากข้อมูลที่ใหม่กว่าอยู่ระหว่างทาง
  เช่นตำแหน่งการหมุน ฯลฯ

นี่เป็นความคิดที่สมเหตุสมผลหรือไม่ ข้อเสียที่เป็นไปได้คืออะไร?
มีวิธีที่ดีกว่าในการจัดการกับสิ่งนี้หรือไม่?

มันส่งผลให้เกิดการสูญเสียแพ็คเก็ตสำหรับ UDP เนื่องจากการช่วงชิงระหว่างสองโปรโตคอล - โปรดจำไว้ว่า UDP ไม่ได้รับประกันการส่งมอบในขณะที่ TCP เป็น แพ็คเก็ต TCP อื่น ๆ จะได้รับผ่านในขณะที่ UDP ทุกข์ - TCP เจือจาง UDP แพ็คเก็ตการสูญเสีย มีความคิด (ประวัติศาสตร์) ว่าโครงสร้างพื้นฐานเราเตอร์ชอบ TCP ผ่าน UDP แต่ฉันสงสัยว่ายังคงเป็นจริงในช่วงปลายนี้

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

ตัวอย่างของสิ่งเหล่านี้คือไลบรารีโอเพนซอร์สEnetคุณลักษณะหลักของมันคือการเลือกส่งที่เชื่อถือได้และเป็นไปตามคำสั่งของแพ็กเก็ตผ่าน UDP

นี่เป็นคำพูดของ Sam Jansen จากความคิดเห็นในgafferongames.com :

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

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

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

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

ในการตอบคำถามของคุณ:

ฉันสงสัยว่ามันสมเหตุสมผลที่จะใช้ทั้ง TCP และ UDP ในเวลาเดียวกัน แต่สำหรับสิ่งต่าง ๆ [... ]

ใช่นี่เป็นสิ่งที่ยอมรับได้หากคุณอยู่ในขอบเขตแบนด์วิดท์

• TCP สำหรับการส่งข้อมูลที่ส่งไม่บ่อยนัก แต่ควรรับประกันว่าจะมาถึงอย่างน่าเชื่อถือ เช่นการอัพเดทคะแนนชื่อของผู้เล่นหรือแม้แต่สถานะเปิด / ปิดของแสงในโลกของเกม

เมื่อใช้ทั้ง TCP และ UDP คุณควรต้องการส่งให้มากที่สุดผ่าน UDP และน้อยที่สุดเท่าที่จะทำได้ผ่าน TCP

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

อาจจะไม่.

UDP ทำงานได้ดีสำหรับกรณีเหล่านี้และQuake 3เป็นตัวอย่างที่ดีของวิธีการ

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

นี่เป็นความคิดที่สมเหตุสมผลหรือไม่

• ใช่

ข้อเสียที่เป็นไปได้คืออะไร?

• การสูญเสียของแพ็คเก็ต, ความซับซ้อนของรหัสมากขึ้น, การเชื่อมต่ออื่น ๆ เพื่อจัดการ == โอกาสมากขึ้นในการยกเลิกการเชื่อมต่อ, หมดเวลา, ยกเว้น, ...

มีวิธีที่ดีกว่าในการจัดการกับสิ่งนี้หรือไม่?

• ใช้ไลบรารี UDP ที่เชื่อถือได้ที่มีอยู่ สองที่ได้รับความนิยม ได้แก่ : Lidgren Network (C #), RakNet (C ++) จากประสบการณ์ฉันสามารถพูดได้ว่า Lidgren นั้นใช้งานง่ายรวดเร็วและเชื่อถือได้

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

ขีด จำกัด ถูกกำหนดโดยการตั้งค่าในระบบเครือข่าย นอกจากนี้ทุกการเชื่อมต่อใช้หน่วยความจำบางส่วนที่ต้องมาจากที่ใดที่หนึ่งบนเซิร์ฟเวอร์

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