Discussion :

[syrald]

Bonjour,

Alors avec un ami, on voulait un peu s'entraîner à utiliser un serveur via une application cliente sous forme de jeu.
Ce qu'on aimerait (pour l'instant), c'est contrôler un personnage et qu'on voit les autres personnages des autres personnes connectées se déplacer aussi.

Vu qu'on est dans du temps réel, on comptait utiliser UDP qui est plus intéressant dans ce contexte (corrigez moi si je me trompe).

Mais du coup je me posais une question. Pour pouvoir se connecter à l'application, imaginons qu'il y ai un système de login/mot de passe classique. Les informations à envoyer étant importantes, pour moi il faudrait passer par TCP cette fois-ci (corrigez moi encore si je me trompe :p). Bien entendu c'est un exemple, mais si on veut aussi ajouter un tchat et d'autres fonctionnalités de ce type,... Rien que pour vérifier que l'utilisateur soit bien connecté au serveur, l'UDP n'est pas la bonne solution (je crois). Donc il me faudrait deux serveurs: Un TCP et un UDP.

Sauf que je vois un peu partout sur le net qu'il ne faut pas utiliser TCP et UDP sauf dans des cas précis. Est-ce que dans mon cas, je suis dans un cas précis ou alors je suis totalement à côté de la plaque?

Merci d'avance pour vos réponses et conseils

PS: J'espère être dans la bon forum, j'ai hésité avec Réseau -> Développement

[becket]

TCP ou UDP ?

Si tu pars sur l'idée d'écrire un nouveau protocole. Tu peux le faire aussi bien en TCP qu'en UDP mais tu dois être conscient des différences fondamentales entre les deux.
En udp, par exemple, rien ne t’empêche de créer :

• une authentification par login/mdp et de gérer un système de token ( ou autre )
• Un authentification de chaque message.
• Un système sans authentification mais utilisant massivement les système de crytographie asymetrique

[syrald]

Merci pour ta réponse!

Je pensais pas créer un protocole (pour l'instant), je me posais la question d'utiliser soit l'un, soit l'autre, soit les deux sur deux ports différents.
Comme tout ça c'est plus du bidouillage et de l'entrainement, on pensait d'abord utiliser TCP et/ou UDP puis ensuite voir avec la création de notre propre protocole.

Du coup si j'envoie l'authentification par UDP et que pas de chance, le paquet se perds. Je suis censé faire comment moi ? :p
D'où la question d'utiliser TCP dans ce cas là...
En UDP ce qui me pose problème c'est le fait qu'un paquet puisse être perdu et pas que l'ordre des paquets ne soient pas forcément le même entre l'envoi et la réception.

[gael21]

En fait le grand classic dans ces cas est de faire une encapsulation des deux protocoles.
Je m'explique:
Le protocole TCP est un protocole qui fonctionne en mode connecté. Donc dans son fonctionnement il gère les accusés de réceptions et par conséquent il est lent.
Le protocole UDP de son coté fonctionne en mode non-connecté. Donc il ne gère pas vraiment les accusés de réception et par conséquent il est plus rapide et adapté au temps réel.
Alors pour gérer à la fois le temps réel et le contrôle des erreur de messages, il faut encapsuler le protocole UDP dans le TCP. c-à-d aux extrémités, tu as le TCP et à l'intérieur tu as l'UDP

[chrtophe]

A mon avis, encapsuler de l'UDP dans du TCP n'apporte rien mis à part de la lourdeur.. Tu peux envisager de faire une double communication en UDP pour certains éléments, en TCP pour l'autre.

Si ton trafic n'est pas important, utilises TCP.

Sur le principe, ce que ne fais pas UDP par rapport à TCP peut être géré par ta couche applicative.

[sevyc64]

TCP vs UDP, c'est très simple

TCP :
Tu aborde une personne que tu connais dans la rue, une seule, tu la salue, tu attend qu'elle te rende le salue, tu discute en attendant régulièrement qu'elle réponde à tes propos, etc ...
avantage : échange réel et acquitté pas de données perdues, la perte d'une partie des données corrompt la totalité des données (transfert de fichier par exemple); inconvénient : lourd et lent

UDP :
Tu prends un mega-phone et tu annonce, tout seul, ton message. Tu peux avoir une réponse, par un autre mega-phone, tu peux ne pas en avoir, ça ne t'empêcheras pas de vivre.
bien entendu tu peux rajouter un protocole "logiciel" de communication là-dessus, mais ça ne relève plus de la techno UDP.
inconvénient : pas d’acquittement, tu ne sais pas s'il y avait un destinataire à l'écoute, s'il a reçu, etc ..., possible perte de données; Avantage : léger et rapide, important lorsque la priorité est à la diffusion et non pas au contenu (streaming, voip, etc ...). La perte d'une partie de la donnée ne nuit pas la totalité de l'info dans son ensemble (en voip, la perte d'un phonème n’empêche pas l'interlocuteur de comprendre quand même la phrase complète, par contre il est important de respecter le débit de la parole)
Autre avantage : contacter un destinataire qui n'est pas connu et dont l’existence n'est même pas connue (cf. protocole DHCP)


Pour ton problème, bien entendu que tu peux mixer les 2 protocoles dans la même application.
Et pour le problème d'authentification, tu peux le régler avec les 2 protocoles :
- Authentification en TCP
- si l'authentification est réussi, échange d'un token
- conversation en udp, en passant à chaque fois le token obtenu lors de l'authentification

Ensuite pour maintenir l'authentification, soit, le fait de recevoir un token déjà donné maintient l'authentification correspondante, soit obligation, régulièrement de se ré-authentifier via tcp pour maintenir le token actif.

Tout est faisable, c'est une question d'imagination

[jlliagre]

Tout dépend des contraintes du système.

Si les données transmises doivent l'être à plusieurs destinataires en même temps et que la perte de données n'a pas de conséquences durables (ex: audio, vidéo, capteurs de mesure, positions, etc), UDP s'impose (+broadcast ou multicast)

Si la perte de données n'a pas d'importance, UDP reste un choix possible.

Si la perte de données a des conséquences ennuyeuses, il n'y a pas à hésiter, TCP.

La question du temps réel est hors-sujet dans ce dernier cas. J'ai vu plein de projets temps réel où les développeurs se sont dit que faire de l'UDP serait une bonne idée. Au bout de quelque temps, ils se rendent compte que les paquets arrivent parfois dans le désordre ou n'arrivent simplement jamais. Les développeurs ajoutent alors des fonctionnalités pour permettre au destinataire de redemander à l'émetteur la retransmission des paquets perdus et petit à petit ils réinventent la roue, forcément moins ronde que l'originale.

TCP fait déjà tout ça très bien et très rapidement. On peut tuner les stacks TCP pour avoir un latence basse, diminuer les timeouts en cas de pertes de trames, etc.

[sevyc64]

La question du temps réel est hors-sujet dans ce dernier cas. J'ai vu plein de projets temps réel où les développeurs se sont dit que faire de l'UDP serait une bonne idée. Au bout de quelque temps, ils se rendent compte que les paquets arrivent parfois dans le désordre ou n'arrivent simplement jamais. Les développeurs ajoutent alors des fonctionnalités pour permettre au destinataire de redemander à l'émetteur la retransmission des paquets perdus et petit à petit ils réinventent la roue, forcément moins ronde que l'originale.

Tel que tu le décrits il s'agit ici d'un cas ou "la perte de données a des conséquences ennuyeuses", comme tu dis. Dans une telle situation le choix d'UDP sera toujours un très mauvais choix, quelque soit le contexte et quelque soit les raisons qui poussent à le choisir.

TCP fait déjà tout ça très bien et très rapidement. On peut tuner les stacks TCP pour avoir un latence basse, diminuer les timeouts en cas de pertes de trames, etc.

Sur des flux important de données en continue, TCP, malgré sa grande rapidité apparente, est très lent et gros consommateur de ressource. Il faut dépiler tous les contrôles, faut mettre les paquets en cache le temps de pouvoir les remettre en ordre et reconstruire le data, etc ....
Quant à tuner les stacks, utiliser des trames jumbo, etc ... ça va bien lorsque tu maîtrise les clients et tout le media de transfert. Mais il suffit que tu passe par un réseau que tu ne maîtrise pas (ex : internet) et c'est déjà moins évident de tuner efficacement voire impossible.
Bien évidemment sur des flux peu important TCP peut faire aussi bien qu'UDP

[jlliagre]

Tel que tu le décrits il s'agit ici d'un cas ou "la perte de données a des conséquences ennuyeuses", comme tu dis. Dans une telle situation le choix d'UDP sera toujours un très mauvais choix, quelque soit le contexte et quelque soit les raisons qui poussent à le choisir.

Oui, c'est vrai. Mais j'ai vu suffisamment de projets où les développeurs et architectes ont sous-estimé leur intolérance aux pertes et arrivées désordonnées et le manque de fiabilité d'UDP que je préfère insister là-dessus.

Sur des flux important de données en continue...
...il suffit que tu passe par un réseau que tu ne maîtrise pas (ex : internet)...
Bien évidemment sur des flux peu important TCP peut faire aussi bien qu'UDP

Ca se discute.

Sur des flux vraiment importants de données en continu, et en particulier quand tu passes par des réseaux que tu ne maîtrise pas (Internet), UDP balance les paquets sans se préoccuper du reste. Tu peux alors facilement perdre la quasi totalité des paquets envoyés. De plus, si tu as plusieurs flux en parallèle, il n'y aura pas de régulation et partage équitable de la bande passante disponible.

Avec TCP, tu ne vas pas pouvoir envoyer des paquets plus vite que ne le permet le maillon le plus faible de la chaîne de transmission, TCP autorégule et adapte le trafic aux performances et à l'utilisation par des tiers du support.

Enfin, si le trafic est construit à partir de l'émission de petits blocs de données, TCP, en assemblant les paquets émis peut aussi optimiser la bande passante en augmentant le payload par trame, et faire mieux qu'udp.

En résumé, plus on est proche de la saturation d'un segment du réseau, plus je conseillerais TCP.

Bien sûr, si la perte ou l'arrivée dans le désordre de paquets n'a pas d'importance significative, et si on utilise du multicast, UDP peut être la meilleure ou la seule solution.

Informer de l'arrivée d'un missile dans un jeux vidéo et informer de l'arrivée d'un vrai missile intercontinental ne se conçoit pas forcément avec les mêmes solutions techniques...

La solution de bon sens peut aussi être d'utiliser les deux canaux, du TCP pour les informations importantes et un flux bidirectionnel, et de l'UDP pour envoyer un flux monodirectionnel ou multicast, de la vidéo, de l'audio, des données dont la pertinence et l'utilité expire très rapidement et des détails non critiques.

[BufferBob]

salut,

j'y vais de mon avis également,

Ce qu'on aimerait c'est contrôler un personnage et qu'on voit les autres personnages des autres personnes connectées se déplacer aussi.

Vu qu'on est dans du temps réel, on comptait utiliser UDP (...)

je m'étais intéressé à faire plus ou moins le même genre de choses à une époque, ce qu'il en ressortait (et ce que j'avais pu lire sur le sujet notamment) c'est qu'au delà du protocole réseau c'est surtout de design coté serveur dont il est question

de manière "atomique", comment gère-t-on des évènements simultanés ? par exemple Olaf et Grudu donnent des coups d'épée exactement au même moment, est-ce que le serveur (l'ordonnanceur en fait) honore en mode "1er arrivé, 1er servi" ?

est-ce que l'ensemble du monde est "gelé" pendant quelques cycles (et donc que les clients pendant ce temps ne peuvent pas interagir sur le monde stocké coté serveur) le temps de calculer les interactions et la version modifiée du monde qu'on renvoie ensuite à tous les clients ?

il me semble que c'est plutôt par ce bout là qu'il faut prendre le problème, se poser des questions concrètes relatives au fonctionnement du jeu, le choix des technologies devrait théoriquement en découler assez naturellement

par ailleurs il est question ici de faire ça sur le temps libre à priori, en tous cas pas de faire un serveur capable de tenir une charge de 5000 clients, si on considère qu'au maximum le jeu va tourner sur 10 machines en même temps, la question TCP ou UDP n'a quasiment aucun impact

une idée peut être de créer une gestion du réseau qui fonctionne dans un premier temps sans se soucier des perfs (c'est souvent plus sain d'ailleurs), et ensuite lorsqu'on teste la montée en charge du serveur, sa capacité à gérer plusieurs clients simultanés, envisager des améliorations voire une refonte de la couche réseau

avis perso.

[yotta]

En résumé :
La partie "Contrôle du personnage" serait gérée par TCP (connexion + identification pour la prise de contrôle d'un personnage fourni par le serveur).
En parallèle, le serveur emet via UDP en multicast/unicast c'est vous qui voyez en continue et en temps réel la position de tous les personnages sous contrôle. Le programme client devra simplement utiliser un second canal réseau en UDP pour recevoir les mouvements des personnages. L'utilisation d'un jeton d'identification récupéré par la partie "Contrôle du personnage" permettant de s'inscrire sur le flux UDP.

[Invité]

Tout dépend des contraintes du système.

Oui, tout dépend du jeu de contraintes.

C'est du peer-to-peer ?

Du client/server ?
Le server est en datacenter avec des gros débits sur le net ?

Généralement, les "gros" jeux videos mixent les deux protocoles udp/tcp.
A noter également qu'on peut être connecté en udp... Il suffit que la gestion et le contrôle de flux soient embarqués dans l'application. Ce type d'approche est très utilisé dans le codage des jeux videos.

VX