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?
la source
Réponses:
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.
la source
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.
la source
Il semble que l'une de mes hypothèses était fausse. Selon ceci :
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).
Plus tard:
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.
la source