Discussion :

[yannick1717]

Bonjour,

J'ai dans l'idée de faire un jeu en réseau.
Dans pas mal de systèmes que j'ai pu voir, la ou certaines données qu'il faut envoyer assez souvent (telles que les locations de différents composants qui bougent), j'ai vu qu'on utilisait souvent le protocole UDP.

Est-ce réèlement utile ?

Passerais-je à coté de quelque chose si je faisais tout passer dans le même socket?

Merci à vous

[nouknouk]

salut,

permière chose: je pense que ton post aurait bénéficié d'une meilleure visibilité dans le sous-forum 'développement réseaux'.
Tu y trouveras d'ailleurs plusieurs posts qui se rapprochent pas mal de ta question, par exemple celui-ci.

Pour moi, les points importants dans la comparaison TCP vs UDP:
- UDP n'est réellement indiqué que dans un cas de figure: des données avec une forte contrainte temps-réel. Par exemple les déplacements d'un joueur dans un FPS sont l'exemple typique:
* si on perd un paquet en route, ce n'est pas un drame puisque le paquet suivant rétablira la cohérence de l'environnement de jeu.
* si un paquet est perdu, on ne cherchera pas à le récupérer ensuite, car connaître la position du joueur à l'instant T ne sera plus d'aucune utilité à l'instant T + x.

- UDP fonctionne en mode 'déconnecté'. Il impose donc au joueur placé derrière un NAT (genre ADSL box) de configurer à la main l'ouverture du port sur son NAT (en TCP, l'utilisation d'un serveur relais peut contourner le souci).

- avec UDP, les paquets peuvent être perdus, certes. Mais également arriver dans un ordre quelconque et surtout être corrompus (ie. on reçoit pas les mêmes données que celles qui ont été envoyées). C'est là que se situe la difficulté majeure, car lorsqu'on va programmer la brique réseau, il faudra systématiquement partir du principe que le paquet est corrompu pour envisager tous les cas de figure. Et détecter/corriger ce genre de cas de figure est bien plus complexe qu'on pourrait le penser au départ.

Pour moi, tu as deux solutions:

- dans un premier temps tout faire en TCP pour ne pas complexifier à outrance le code et perdre un temps précieux à implémenter les mécanismes spécifiques à UDP. Si pendant la phase de tests tu te rends compte qu'effectivement le TCP te limite (et que tu as implémenté ta brique réseau de façon suffisamment modulaire), tu pourras toujours faire passer les quelques flux qui posent souci en UDP.

- sinon, tu peux t'appuyer sur des bibliothèques réseau dédiées au jeux (genre TNL, pour Torque Network Library) et qui implémentent déjà les mécanismes avancés dédiés au jeu en réseau (UDP, dead reckoning, ...).

[yannick1717]

C'est noté, merci, tes réferences sont intéressantes.

Je vais faire comme tu dis, laisser porte ouverte à un flux udp dans l'appli sans l'implémenter.

Merci!

[Emmanuel Deloget]

Attention toutefois: l'intérêt d'UDP par rapport à TCP, c'est que le protocole est plus light (certaines données ne sont pas envoyées, ce qui fait que le transfert est vaguement plus rapide). Toutefois, si tu te retrouves dans un configuration ou tu as un risque de perte de paquet non négligeable (ou même d'erreurs), les mécanismes que tu devra mettre en place pour composer ces pertes risquent d'être plus lourd que prévu.

Au final, le transfert des données sera un poil plus rapide mais le traitement des données risque d'être plus long. Il convient donc de faire une étude correcte de ton problème, afin de déterminer l'impact des pertes - par exemple, que se passe-t-il si la commande "equip weapon" est perdus ? Le serveur doit-il envoyer un accusé de réception pour vérifier si la commande est bien passée ? Faut-il la renvoyer ? Quelle est la fréquence d'envoi de cette commande ?

A noter que tu peux aussi t'intéresser à RUDP (Reliable UDP). Ce protocole fonctionne sur une base d'UDP mais intègre des checks qui permette de t'assurer que les données envoyées arrivent (plus ou moins) bien à destination. Certaines implémentations arrivent à garder l'avantage de la rapidité d'UDP tout en fournissant des services qui sont typiquement liés à un protocole fonctionnant en mode connecté.

[nouknouk]

Attention toutefois: l'intérêt d'UDP par rapport à TCP, c'est que le protocole est plus light (certaines données ne sont pas envoyées, ce qui fait que le transfert est vaguement plus rapide).

D'accord pour dire que la structure d'un paquet UDP est plus 'light' qu'un paquet TCP, et donc peut faire gagner un peu en bande passante. Ceci dit, c'est relativement négligeable à moins que la bande passante nécessaire pour l'appli soit (très) grande. Pour info, un quake-like réclame rarement plus de 5ko/sec (à comparer avec un accès ADSL, même en 128k).

Pas d'accord du tout pour la vitesse de transmission de UDP comparativement à TCP : un paquet reste un paquet ralyé par le réseau. Il n'ira pas plus vite parce que c'est un paquet UDP (*). La seule différence est que si un paquet TCP est perdu ou altéré, la pile protocolaire essaiera de le renvoyer avant d'envoyer les paquets suivants.
Dans le cas où effectivement, un paquet perdu n'a plus d'intérêt d'être renvoyé ensuite, cela aura pour conséquence de ralentir l'arrivée des paquets suivants.
Donc, quitte risque de me répéter, un paquet UDP ne va pas plus vite qu'un paquet TCP, ce sont les mécanismes de ré-émission qui sont plus contraignants.

Ceci est à pondérer largement avec le taux de perte / altération des paquets sur nos lignes actuelles (ADSL pour la plupart). Dans cet optique, on voit que le taux de perte d'un paquet TCP est très (très) faible, et que même les flux 'temps réel' s'accomodent très bien du TCP. Un bon exemple: la VoIP (genre Skype) bascule automatiquement en TCP lorsqu'on est derrière un NAT (et sans redirection du bon port). Elle reste pourtant tout à fait utilisable.

(*) Pour être complet: TCP est un poil plus lent qu'UDP parce que: 1- pour des raisons hardwares au niveau des routeurs (lecture et parsing de l'adresse de destination) 2- plus de traitement pour la pile réseau de chaque terminal (émetteur, récepteur). Mais dans ces deux cas, on parle de microsecondes, donc quelque chose de tout à fait négligeable.