วิธีการหลีกเลี่ยงการควบคุมปริมาณ?

ฉันกำลังเขียนเกม iOS บนเครือข่าย เมื่อส่งแพ็คเก็ตที่มีGKMatchSendDataReliable(ซึ่งฉันสันนิษฐานว่าเป็น UDP พร้อมรหัสรับแพ็คเก็ตของตัวเองเขียน) ที่ 60 แพ็คเก็ตต่อวินาที (ดังนั้น 16 ms ระหว่างแพ็คเก็ตที่อยู่ติดกัน) เวลา ping เฉลี่ยแย่ลงอย่างรวดเร็ว: ) และเพียงแค่ส่ง "ท่วม" จาก 100 แพ็คเก็ต (ในอัตรา 60 แพ็คเก็ตต่อวินาที) ฉันวัดเวลาไปกลับโดยเฉลี่ยและนี่คือผลลัพธ์:

[ 21:16:39 ]:  I saw an average roundtrip time of 52.342787 ms, he saw 54.496590 ms
[ 21:16:34 ]:  I saw an average roundtrip time of 62.631942 ms, he saw 61.991655 ms
[ 21:16:45 ]:  I saw an average roundtrip time of 88.394380 ms, he saw 83.619123 ms
[ 21:16:51 ]:  I saw an average roundtrip time of 179.053118 ms, he saw 156.869141 ms
[ 21:16:57 ]:  I saw an average roundtrip time of 75.025076 ms, he saw 75.419723 ms
[ 21:17:23 ]:  I saw an average roundtrip time of 8832.082488 ms, he saw 7616.877558 ms
[ 21:19:33 ]:  I saw an average roundtrip time of 25088.962344 ms, he saw 16833.064914 ms

หลังจากการทดสอบ 2 ครั้งล่าสุดผลลัพธ์จะอยู่ที่ประมาณ 1,000 ms

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

เมื่อฉันเปลี่ยนอัตราการส่งแพ็คเก็ตเป็นช้าลง 10 เท่า (ดังนั้น 1 แพ็คเก็ตทุก 160 มิลลิวินาที) การทดสอบใช้เวลานานกว่ามาก แต่เวลาไปกลับยังคงต่ำอย่างต่อเนื่อง

[21:31:27]: ฉันเห็นเวลาไปกลับโดยเฉลี่ย 55.289109 ms เขาเห็น 69.032727 ms

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

ฉันกำลังมองหาแนวทางเกี่ยวกับจำนวนแพ็กเก็ต UDP ที่ฉันสามารถส่งได้ต่อวินาทีเพื่อหลีกเลี่ยงการถูก จำกัด ปริมาณ! มีแนวทางทั่วไปใด ๆ บ้างไหม?

ไม่ใช่แม้แต่เกมแอคชั่นที่ใช้กับพีซีหรือ MMO ขนาดใหญ่ที่ใช้งานแพ็คเก็ตที่ความเร็ว 60Hz นอกจากนี้การมีขนาดแพ็คเก็ตที่เล็กมากนั้นไม่ได้เป็นสิ่งที่ยอดเยี่ยม แต่อย่างใดแพ็คเก็ตเล็ก ๆ เหล่านั้นมีค่าใช้จ่ายสูงในการส่งมันออกมา

ลองถ่ายภาพเพื่ออัปเดต 10Hz ด้วยการแก้ไขบางอย่างที่ฝั่งไคลเอ็นต์ ฉันคิดว่าคุณกำลังแก้ไขอยู่เพราะมีความล่าช้าในการปิงอยู่เสมอ

อ่านข้อมูลเกี่ยวกับขนาด MTU และทำการโยนข้อมูลเพิ่มเติมเพื่อให้ครอบคลุมระยะเวลาที่นานขึ้น ขนาดแพ็คเก็ตเฉลี่ยที่ชั้นการขนส่งจะเท่ากับ 1,400 หรือมากกว่านั้นสิ่งที่เกินขนาด MTU จะแบ่งข้อความของคุณและทำให้ค่าใช้จ่ายมากขึ้น

ก่อนอื่นคุณต้องแน่ใจว่าข้อมูลทั้งหมดมีขนาดใหญ่เพียงใด ISP ของคุณน่าจะสนใจไบต์ที่ส่งจริงไม่ใช่จำนวนหรือความถี่ของดาตาแกรม หากคุณกำลังส่งดาต้าแกรมขนาดสูงสุด (65507 ส่วนของเพย์โหลด) 60 ครั้งต่อวินาทีคุณกำลังส่งอัปสตรีมประมาณ 30 Mb / s ไม่ใช่ทุกคนที่มีความสัมพันธ์แบบนั้น

จำไว้ว่า IP header นั้นยาว 20 octets และ UDP header นั้นยาว 8 octets นั่นคืออีก 28 อ็อกเท็ตที่คุณส่งไปสำหรับแต่ละดาตาแกรม

หากคุณไม่ได้เชื่อมต่อให้ได้สูงสุดมีหลายสถานที่ที่แพ็คเก็ตของคุณอาจล่าช้า: เช่นระบบปฏิบัติการของลูกค้า, เกตเวย์ของคุณ (อาจเป็นเราเตอร์ไร้สายหรือเคเบิลโมเด็ม), ISP ของคุณ, ISP ของผู้ให้บริการรายอื่น gateway, ระบบปฏิบัติการอื่น ๆ

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

มีหลายวิธีที่คุณสามารถวินิจฉัยทราฟฟิกเครือข่ายด้วย Wireshark:

• ใช้ Wireshark ในพีซีในเครือข่ายเดียวกับอุปกรณ์พกพาที่มีฮับที่หลากหลายและตั้งค่าอุปกรณ์เครือข่ายของคุณว่ามีความหลากหลาย

• ตั้งค่าพีซีเป็นเกตเวย์ไร้สายและเชื่อมต่ออุปกรณ์พกพาของคุณกับเกตเวย์นั้นจากนั้นฟัง Wireshark บนพีซีดังกล่าว

• เรียกใช้ Wireshark ในเครื่องเดียวกับโปรแกรมจำลอง

• เรียกใช้ tcpdump ในอุปกรณ์ของตัวเอง (ง่าย ๆ สำหรับ Android ต้องใช้การเจลเบรคบน iOS) จากนั้นอ่านข้อมูลที่ถ่ายบน Wireshark

• สร้างโปรแกรมอย่างง่ายที่ทำสิ่งเดียวกัน แต่ใช้กับพีซีและใช้ Wireshark ในนั้น

• ... และอื่น ๆ อีกมากมาย

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

โดยปกติหากคุณได้รับการควบคุมปริมาณโดยเครือข่ายคุณควรได้รับ ICMP type 4 datagrams เพื่อให้คุณสามารถใช้เพื่อตรวจสอบว่าคุณได้รับการควบคุมปริมาณ

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

ดูเหมือนว่าหนึ่งในสมมติฐานของฉันผิด ตามนี้ :

โหมด GKMatchSendDataUnabled, ภาพที่จะส่งใน UDP ที่เรียกว่า ภาพโหมด GKMatchSendDataReliable ส่งโดย TCP ควรเป็น GKMatchSendData ไม่น่าเชื่อถือโดยปกติ

การเปลี่ยนโหมดส่งเป็น UDP จริง (เช่นGKMatchSendDataUnreliable) จะปรากฏขึ้นเพื่อรักษาอัตรา ping ต่ำที่ 60 แพ็กเก็ตต่อวินาที ดูเหมือนว่าฉันได้รับการตีด้วย Nagles อีกครั้ง

ฉันยังคงมีพฤติกรรมแปลก ๆ (ช่วงเวลาที่มีค่า ping สูงมาก) แต่ฉันไม่แน่ใจว่าสาเหตุที่แท้จริง (ISP หรือความแออัดของเครือข่าย)

[ 10:30:33 ]:  I saw an average roundtrip time of 39.908923 ms, he saw 48.437794 ms
[ 10:30:39 ]:  I saw an average roundtrip time of 26.278577 ms, he saw 27.023854 ms
[ 10:30:48 ]:  I saw an average roundtrip time of 23.254163 ms, he saw 24.495182 ms
[ 10:30:54 ]:  I saw an average roundtrip time of 37.333127 ms, he saw 34.780404 ms
[ 10:31:03 ]:  I saw an average roundtrip time of 29.198575 ms, he saw 29.071106 ms
[ 10:31:11 ]:  I saw an average roundtrip time of 49.030299 ms, he saw 48.675459 ms
[ 10:31:18 ]:  I saw an average roundtrip time of 34.031792 ms, he saw 34.698117 ms
[ 10:31:24 ]:  I saw an average roundtrip time of 30.058642 ms, he saw 32.814952 ms
[ 10:31:30 ]:  I saw an average roundtrip time of 53.110438 ms, he saw 54.271453 ms
[ 10:31:45 ]:  I saw an average roundtrip time of 119.693933 ms, he saw 107.616359 ms
[ 10:31:50 ]:  I saw an average roundtrip time of 222.644443 ms, he saw 229.589861 ms
[ 10:31:57 ]:  I saw an average roundtrip time of 166.827070 ms, he saw 167.647724 ms
[ 10:32:05 ]:  I saw an average roundtrip time of 765.356593 ms, he saw 859.600923 ms
[ 10:32:13 ]:  I saw an average roundtrip time of 357.522686 ms, he saw 339.648654 ms
[ 10:32:24 ]:  I saw an average roundtrip time of 1115.639593 ms, he saw 1060.574401 ms
[ 10:32:39 ]:  I saw an average roundtrip time of 175.845995 ms, he saw 171.112166 ms
[ 10:32:44 ]:  I saw an average roundtrip time of 47.262925 ms, he saw 41.987869 ms
[ 10:32:52 ]:  I saw an average roundtrip time of 74.524443 ms, he saw 78.868198 ms
[ 10:33:47 ]:  I saw an average roundtrip time of 20.943917 ms, he saw 21.217377 ms
[ 10:33:52 ]:  I saw an average roundtrip time of 28.944821 ms, he saw 29.303144 ms
[ 10:34:06 ]:  I saw an average roundtrip time of 25.581624 ms, he saw 25.439416 ms
[ 10:34:13 ]:  I saw an average roundtrip time of 25.565568 ms, he saw 25.655267 ms
[ 10:34:18 ]:  I saw an average roundtrip time of 38.609394 ms, he saw 37.462835 ms

ต่อมา:

[ 10:38:11 ]:  I saw an average roundtrip time of 40.037623 ms, he saw 43.367524 ms
[ 10:38:21 ]:  I saw an average roundtrip time of 121.222703 ms, he saw 118.855264 ms
[ 10:38:28 ]:  I saw an average roundtrip time of 726.391897 ms, he saw 685.742454 ms
[ 10:38:33 ]:  I saw an average roundtrip time of 60.251207 ms, he saw 57.974503 ms
[ 10:38:42 ]:  I saw an average roundtrip time of 1133.909392 ms, he saw 1124.404501 ms     

ดังนั้นมันเป็นระยะ ๆ และไปในคลื่น ฉันเดาว่าฉันจะต้องลองคำแนะนำในกระทู้อื่น ๆ เช่นลดอัตราการส่งแพ็คเก็ตของฉัน