Discussion: TCP et/ou UDP?

  1. #1
    Membre habitué
    Homme Profil pro
    Étudiant
    Inscrit en
    mars 2017
    Messages
    114
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 23
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mars 2017
    Messages : 114
    Points : 148
    Points
    148

    Par défaut TCP et/ou UDP?

    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

  2. #2
    Membre expert
    Avatar de becket
    Profil pro
    Informaticien multitâches
    Inscrit en
    février 2005
    Messages
    1 588
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Informaticien multitâches
    Secteur : Service public

    Informations forums :
    Inscription : février 2005
    Messages : 1 588
    Points : 3 370
    Points
    3 370

    Par défaut

    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

  3. #3
    Membre habitué
    Homme Profil pro
    Étudiant
    Inscrit en
    mars 2017
    Messages
    114
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 23
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : mars 2017
    Messages : 114
    Points : 148
    Points
    148

    Par défaut

    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.

  4. #4
    Membre à l'essai Avatar de gael21
    Homme Profil pro
    Étudiant
    Inscrit en
    mai 2016
    Messages
    9
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2016
    Messages : 9
    Points : 10
    Points
    10

    Par défaut

    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

  5. #5
    Responsable Systèmes


    Homme Profil pro
    Technicien maintenance
    Inscrit en
    août 2011
    Messages
    8 926
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : août 2011
    Messages : 8 926
    Points : 19 791
    Points
    19 791

    Par défaut

    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.
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur la création d'un système : http://chrtophe.developpez.com/tutoriels/minisysteme/
    Mon article sur le P2V : http://chrtophe.developpez.com/tutoriels/p2v/
    Consultez nos FAQ : Windows, Linux, Virtualisation

  6. #6
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    9 358
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 9 358
    Points : 25 072
    Points
    25 072

    Par défaut

    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
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  7. #7
    Modérateur
    Avatar de jlliagre
    Homme Profil pro
    Ingénieur support avancé & développement
    Inscrit en
    juin 2007
    Messages
    2 693
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur support avancé & développement
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2007
    Messages : 2 693
    Points : 7 853
    Points
    7 853

    Par défaut

    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.
    ɹǝsn *sıɹɐlos*

  8. #8
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    9 358
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 9 358
    Points : 25 072
    Points
    25 072

    Par défaut

    Citation Envoyé par jlliagre Voir le message
    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.

    Citation Envoyé par jlliagre Voir le message
    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
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  9. #9
    Modérateur
    Avatar de jlliagre
    Homme Profil pro
    Ingénieur support avancé & développement
    Inscrit en
    juin 2007
    Messages
    2 693
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur support avancé & développement
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juin 2007
    Messages : 2 693
    Points : 7 853
    Points
    7 853

    Par défaut

    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.
    ɹǝsn *sıɹɐlos*

  10. #10
    Expert éminent Avatar de BufferBob
    Profil pro
    responsable R&D vidage de truites
    Inscrit en
    novembre 2010
    Messages
    2 499
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : responsable R&D vidage de truites

    Informations forums :
    Inscription : novembre 2010
    Messages : 2 499
    Points : 6 715
    Points
    6 715

    Par défaut

    salut,

    j'y vais de mon avis également,
    Citation Envoyé par syrald Voir le message
    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.
    Avant donc que d'écrire, apprenez à penser.
    Selon que notre idée est plus ou moins obscure, l'expression la suit, ou moins nette, ou plus pure.
    Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément.
                                                        - Nicolas Boileau, L'Art poétique

  11. #11
    Membre expérimenté
    Avatar de yotta
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    septembre 2006
    Messages
    953
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2006
    Messages : 953
    Points : 1 377
    Points
    1 377

    Par défaut

    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.
    Une technologie n'est récalcitrante que par ce qu'on ne la connait et/ou comprend pas, rarement par ce qu'elle est mal faite.
    Et pour cesser de subir une technologie récalcitrante, n'hésitez surtout pas à visiter les Guides/Faq du site !

    Voici une liste non exhaustive des tutoriels qui me sont le plus familiers :
    Tout sur Java, du débutant au pro : https://java.developpez.com/cours/
    Tout sur les réseaux : https://reseau.developpez.com/cours/
    Tout sur les systèmes d'exploitation : https://systeme.developpez.com/cours/
    Tout sur le matériel : https://hardware.developpez.com/cours/

  12. #12
    Membre habitué
    Homme Profil pro
    Architecte réseau
    Inscrit en
    avril 2018
    Messages
    69
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Architecte réseau
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : avril 2018
    Messages : 69
    Points : 134
    Points
    134

    Par défaut

    Citation Envoyé par jlliagre Voir le message
    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

Discussions similaires

  1. TCP et/ou UDP pour un jeux de type RTS
    Par coupecoupe dans le forum Développement
    Réponses: 1
    Dernier message: 04/01/2012, 22h29
  2. [Stratégie] Choix UDP ou TCP
    Par Yevetrovitch dans le forum Développement
    Réponses: 17
    Dernier message: 08/02/2005, 10h32
  3. Programme permettant de créer ses propres paquets TCP/UDP
    Par mat087 dans le forum Développement
    Réponses: 6
    Dernier message: 21/05/2004, 21h42
  4. Ping sous protocole TCP (et non UDP)
    Par ovdz dans le forum Développement
    Réponses: 2
    Dernier message: 19/06/2003, 14h10
  5. Différence entre TCP, UDP, ICMP
    Par GliGli dans le forum Développement
    Réponses: 1
    Dernier message: 13/09/2002, 08h25

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo