Bagaimana cara menghindari terkekeh?


9

Saya sedang menulis game iOS jaringan. Ketika mengirim paket dengan GKMatchSendDataReliable(yang saya asumsikan adalah UDP dengan kode penerimaan paket mereka sendiri ditulis) pada 60 paket per detik (jadi 16 ms antara paket yang berdekatan), waktu ping rata-rata dengan cepat menjadi lebih buruk: Saya membuka 7 pertandingan GameCenter di bawah ini (satu demi satu ) dan hanya mengirim "banjir" 100 paket (dengan kecepatan 60 paket per detik). Saya mengukur waktu pulang pergi rata-rata, dan ini adalah hasilnya:

[ 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

Setelah 2 tes terakhir hasilnya sekitar 1000 ms.

Tampaknya saya diperlambat, kemungkinan besar oleh ISP saya. Karena ini adalah permainan iOS, orang akan menggunakan koneksi perumahan biasa.

Ketika saya mengubah kecepatan pengiriman paket menjadi 10 kali lebih lambat (jadi 1 paket setiap 160 ms), pengujiannya memakan waktu lebih lama, tetapi waktu bolak-balik tetap rendah secara konsisten.

[21:31:27]: Saya melihat waktu pulang pergi rata-rata 55.289109 ms, ia melihat 69.032727 ms

Jadi sepertinya menjaga latensi rendah pada koneksi (dan tidak akan "dihukum" oleh ISP) saya harus mengurangi tingkat paket yang saya kirim. Perlu diingat bahwa ini adalah paket yang sangat kecil, seperti maksimum 40 byte, namun saya masih dibatasi.

Saya mencari pedoman tentang berapa banyak paket UDP yang dapat saya kirim per detik untuk menghindari terkekeh! Apakah ada pedoman umum di mana saja?


Sudahkah Anda menguji? Apa yang terjadi jika Anda turun ke 10 paket / detik? Apakah Anda sangat tercekik? Ini bisa membantu menjawab bagian terakhir dari pertanyaan Anda.
notlesh

"Kamu bisa tahu banyak tentang seorang pria dengan cara dia mencekikmu ..." Oh maksudmu definisi 'throttle': P
Casey

Pastikan Anda tidak hanya menjenuhkan koneksi Anda dengan sistem andal apa pun yang telah Anda bangun di atas UDP. Ketika UDP mulai putus, sistem pemulihan ad-hoc cenderung agak sulit untuk diperbaiki. Jangan pernah mengaitkan dengan kedengkian yang bisa dijelaskan oleh ...
Lars Viklund

Tampaknya saya mungkin telah melakukan kesalahan. Itu mungkin lagi NAGLES.
bobobobo

Jawaban:


9

Bahkan game aksi berbasis rumahan atau MMO besar tidak menjalankan paket mereka pada 60Hz. Ditambah memiliki ukuran paket yang sangat kecil belum tentu merupakan hal yang hebat, masing-masing paket kecil tersebut memiliki overhead yang besar hanya dengan mengirimkannya.

Cobalah memotret untuk pembaruan 10Hz dengan interpolasi sisi klien. Saya berasumsi bahwa Anda sudah melakukan interpolasi karena akan selalu ada penundaan ping.

Baca tentang ukuran MTU dan berikan lebih banyak info di sana untuk menutupi jangka waktu yang lebih lama. Ukuran paket rata-rata pada lapisan transpor adalah 1400 atau lebih, apa pun di atas ukuran MTU akan membagi pesan Anda dan menyebabkan lebih banyak overhead.


7

Pertama, Anda harus memastikan seberapa besar seluruh data. ISP Anda kemungkinan besar akan peduli dengan byte aktual yang dikirim, bukan jumlah atau frekuensi datagram. Jika Anda mengirim datagram berukuran maksimum (65507 payload) 60 kali per detik, Anda mengirim sekitar 30 Mb / s ke hulu. Tidak semua orang memiliki koneksi semacam itu.

Ingat bahwa tajuk IP memiliki panjang 20 oktet, dan tajuk UDP memiliki panjang 8 oktet. Itu adalah 28 oktet tambahan yang Anda kirim untuk setiap datagram.

Jika Anda tidak memaksimalkan koneksi Anda, ada banyak tempat di mana paket Anda mungkin tertunda: yaitu OS klien, gateway Anda (mungkin router nirkabel atau modem kabel), ISP Anda, ISP rekan lain, ISP lain gateway, OS rekan lainnya antara lain.

Jika Anda belum menggunakannya, saya sarankan Anda menggunakan Wireshark , yang merupakan alat yang sangat kuat untuk mendiagnosis masalah jaringan. Anggap itu setara dengan debugger, tetapi untuk jaringan.

Ada beberapa cara Anda dapat mendiagnosis lalu lintas jaringan dengan Wireshark:

  • Gunakan Wireshark di PC di jaringan yang sama dengan perangkat seluler, dengan hub yang bebas pilih-pilih dan atur perangkat jaringan Anda sebagai promiscuous

  • Atur PC sebagai gateway nirkabel dan sambungkan perangkat seluler Anda ke gateway itu, lalu dengarkan dengan Wireshark pada PC tersebut

  • Jalankan Wireshark di mesin yang sama dengan emulator

  • Jalankan tcpdump di perangkat itu sendiri (mudah di Android, membutuhkan jailbreak di iOS), dan kemudian baca data yang diambil di Wireshark

  • Buat program sederhana yang melakukan hal yang persis sama, tetapi itu bekerja pada PC, dan gunakan Wireshark di sana.

  • ... dan banyak lagi

Anda ingin memeriksa paket mana yang dikirim, dan kapan. Misalnya, jika penundaan terjadi sebelum dikirim, Anda dihambat oleh OS; sementara jika Anda mendapatkan penundaan bahkan pada versi desktop dari program yang sama, ini berarti Anda sedang diperketat oleh jaringan di suatu tempat.

Biasanya, jika Anda mendapatkan pembatasan oleh jaringan, Anda harus mendapatkan datagram tipe 4 ICMP, sehingga Anda dapat menggunakannya untuk memeriksa di mana tepatnya Anda mendapatkan pembatasan.

Sebagai kesimpulan, ada banyak alasan mengapa paket Anda mungkin tertunda, dan akan lebih bijaksana untuk mencari tahu di mana masalahnya sebelum Anda mulai mencoba menyelesaikan masalah.


0

Tampaknya salah satu asumsi saya salah. Menurut ini :

Mode GKMatchSendDataUnr reliable, gambar yang akan ditransmisikan dalam apa yang disebut UDP. Mode gambar GKMatchSendDataR reliable dikirim oleh TCP. Haruskah itu menjadi GKMatchSendDataUnr Handal biasanya.

Mengubah mode kirim ke UDP nyata (yaitu GKMatchSendDataUnreliable) tampaknya mempertahankan tingkat ping rendah pada 60 paket per detik. Sepertinya aku sudah dikejutkan oleh Nagles lagi .

Saya masih mendapatkan perilaku aneh (periode dengan waktu ping yang sangat tinggi), tapi saya tidak yakin penyebab dasarnya (ISP atau kemacetan jaringan).

[ 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

Kemudian:

[ 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     

Jadi ini sporadis dan berjalan bergelombang. Saya kira saya harus mencoba beberapa saran di posting lain seperti mengurangi tingkat pengiriman paket saya.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.