Comment éviter d'être étranglé?

J'écris un jeu iOS en réseau. Lors de l'envoi de paquets avec GKMatchSendDataReliable(que je supposais être UDP avec leur propre code de réception de paquets écrit) à 60 paquets par seconde (donc 16 ms entre les paquets adjacents), les temps de ping moyens s'aggravent rapidement: j'ai ouvert 7 matchs GameCenter ci-dessous (l'un après l'autre) ) et a simplement envoyé un «flot» de 100 paquets (à raison de 60 paquets par seconde). J'ai mesuré le temps moyen aller-retour, et voici les résultats:

[ 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

Après les 2 derniers tests, les résultats sont d'environ 1000 ms.

Il semblerait que je suis étranglé, probablement par mon FAI. Parce que c'est un jeu iOS, les gens utiliseront des connexions résidentielles régulières.

Lorsque j'ai modifié le taux d'envoi des paquets à 10 fois plus lentement (donc 1 paquet toutes les 160 ms), les tests prennent beaucoup plus de temps, mais les temps d'aller-retour restent constamment bas.

[21:31:27]: J'ai vu un temps d'aller-retour moyen de 55,289109 ms, il a vu 69,032727 ms

Il semble donc que pour garder une faible latence sur la connexion (et ne pas être «puni» par les FAI), je dois réduire le taux de paquets que j'envoie. Gardez à l'esprit que ce sont de très petits paquets, comme 40 octets maximum, mais je suis toujours limité.

Je cherche des directives sur le nombre de paquets UDP que je peux envoyer par seconde pour éviter d'être étranglé! Y a-t-il des directives générales quelque part?

Même les jeux d'action sur PC à domicile ou les grands MMO n'exécutent pas leurs paquets à 60 Hz. De plus, avoir de très petites tailles de paquets n'est pas nécessairement une bonne chose, chacun de ces minuscules paquets a un gros surcoût à envoyer.

Essayez de prendre des mises à jour à 10 Hz avec une interpolation côté client. Je suppose que vous interpolez déjà car il y aura toujours des retards de ping.

Renseignez-vous sur les tailles MTU et ajoutez plus d'informations pour couvrir la période plus longue. Une taille de paquet moyenne au niveau de la couche de transport sera d'environ 1400, tout ce qui dépasse la taille MTU divisera votre message et provoquera encore plus de surcharge.

Tout d'abord, vous devez vous assurer de la taille de l'ensemble des données. Votre FAI se souciera très probablement des octets réels envoyés, et non de la quantité ou de la fréquence des datagrammes. Si vous envoyez des datagrammes de taille maximale (65507 octets de charge utile) 60 fois par seconde, vous envoyez environ 30 Mb / s en amont. Tout le monde n'a pas ce genre de connexion.

N'oubliez pas que l'en-tête IP est long de 20 octets et que l'en-tête UDP est long de 8 octets. C'est 28 octets supplémentaires que vous envoyez pour chaque datagramme.

Si vous ne maximisez pas votre connexion, il existe de nombreux endroits où vos paquets peuvent être retardés: à savoir le système d'exploitation du client, votre passerelle (probablement un routeur sans fil ou un modem câble), votre FAI, le FAI de l'autre pair, l'autre pair passerelle, l'OS de l'autre pair entre autres.

Si vous ne l'avez pas encore utilisé, je vous recommande d'utiliser Wireshark , qui est un outil extrêmement puissant pour diagnostiquer les problèmes de réseau. Considérez-le comme l'équivalent d'un débogueur, mais pour le réseautage.

Il existe plusieurs façons de diagnostiquer le trafic réseau avec Wireshark:

• Utilisez Wireshark dans un PC sur le même réseau que l'appareil mobile, avec un concentrateur de proximité et en définissant votre appareil de réseau comme proche

• Définissez un PC comme passerelle sans fil et connectez votre appareil mobile à cette passerelle, puis écoutez avec Wireshark sur ledit PC

• Exécutez Wireshark sur la même machine qu'un émulateur

• Exécutez tcpdump dans l'appareil lui-même (facile sur Android, nécessite un jailbreak sur iOS), puis lisez les données capturées sur Wireshark

• Créez un programme simple qui fait exactement la même chose, mais qui fonctionne sur un PC, et utilisez Wireshark dedans.

• ... et plein d'autres

Vous voulez vérifier quels colis sont envoyés et quand. Par exemple, si le retard se produit avant leur envoi, vous êtes étranglé par le système d'exploitation; alors que si vous obtenez le retard même sur une version de bureau du même programme, cela signifie que vous êtes étranglé par le réseau quelque part.

Habituellement, si vous êtes étranglé par le réseau, vous devez obtenir des datagrammes ICMP de type 4, afin que vous puissiez les utiliser pour vérifier où vous êtes étranglé.

En conclusion, il existe de nombreuses raisons pour lesquelles vos packages peuvent être retardés, et il serait sage de savoir où est le problème avant de commencer à tenter de le résoudre.

Il semble que l'une de mes hypothèses était fausse. Selon ceci :

GKMatchSendDataUnreliable mode, l'image à transmettre dans le soi-disant UDP. Image en mode GKMatchSendDataReliable envoyée par TCP. Faut-il généralement un GKMatchSendDataUnreliable.

Changer le mode d'envoi en UDP réel (c'est-à-dire GKMatchSendDataUnreliable) semble maintenir des taux de ping faibles à 60 paquets par seconde. On dirait que j'ai été frappé par Nagles encore une fois .

J'obtiens toujours un comportement étrange (périodes avec des temps de ping très élevés), mais je ne suis pas sûr de la cause première (FAI ou congestion du réseau).

[ 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

Plus tard:

[ 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     

C'est donc sporadique et va par vagues. Je suppose que je devrai essayer certaines des suggestions dans les autres articles, telles que la réduction de mon taux d'envoi de paquets.