Discussion :

[john93]

Bonjour a tous.

Voila , je vais faire au plus vite :

problème : je veu faire une application client serveur par internet, au cours de mes étude j'ai beaucoup utilisé le mode udp. j'ai deja conçus l'application quand je configure pour envoyer les donnée sur ma propre machine cela fonctione mais lorsque je veu les envoyer a un amis par internet cela ne fonctione pas.

question :
- le mode udp n'est pas le meilleur moyen d'envoyer des données par internet ?
- quel mode conseillez vous ?

merci pour vos réponse et explication sur le sujet

[john93]

je pense que je n'utilise pas le bon mode de connexion.

le TCP permet lui de contrôler la réception d'après ce que j'ai compris.

qu'es ce que vous en pensez ?

[ram-0000]

Le mode TCP est un mode connecté, le mode UDP est un mode non connecté.
En TCP tu as la garantie que le paquet arrive à destination et s'il n'arrive pas, tu as la garantie de le savoir. En UDP, tu ne PEUX pas savoir si le paquet est arrivé.

Le mode TCP te permet du controle de flux avec la notion de fenetre d'envoi. Ceci n'existe pas en UDP.

Le mode TCP te garantie que les paquets arriveront dans le même ordre que lors de l'envoi. En UDP, un paquet peut en "doubler" un autre (suivant les caprices du routage).

Un socket TCP consomme plus de ressources sur une machine (contexte à maintenir, buffer de réception pour réorganiser les données, ...). Un socket UDP en consomme moins.

Au niveau programmation, le socket UDP est plus facile à gérer que le socket TCP (bien que la difficulté ne soit pas beaucoup plus grande).

TCP est plutôt utilisé pour l'échange de données (FTP, Telnet, WWW, ...) et pour les protocoles dans lesquels la notion de session et d'identification/authentification a un sens.

UDP est plutôt utilisé pour la notification ou les protocoles très simples (SNMP, Syslog, Time, ...)

Ceci dit, il y a des protocoles complexes implémentés sur UDP (NFS par exemple)

Voila, tout cela, c'est des généralités et chacuns des points que j'ai dit possède son contre exemple. Maintenant, tu peux choisir TCP ou UDP.

[john93]

merci ram_0000 je vais utiliser TCP alors.

[nicroman]

En TCP tu as la garantie que le paquet arrive à destination et s'il n'arrive pas, tu as la garantie de le savoir.

C'est même encore pire... et résumé en une seule phrase: "TCP assure que *tous* les paquets arrivent *dans le même ordre* que leur envoi".
Sinon, il y a erreur de connection et celle ci est interrompue.
La seule garantie inexistante concerne le délai d'acheminement.

La façon dont c'est implémenté (au dessus de IP) n'a que peu d'interêt pour cette discussion.

UDP est juste une surcouche au dessus de IP (rajout des ports TCP/IP).
UDP ne garantie rien *du tout* (ni la réception, ni l'ordre, ni même le délai d'acheminement).

UDP c'est du "fire and forget" particulièrement adapté à tout ce qui est 'temps réel'. Et le programmeur a la charge des algorightmes de: rejet des vieux paquets (j'en ai déjà vu arriver avec 1 minute de retard) ou des paquets déjà reçus (ça peut arriver !) acknowledgement des paquets 'importants' (et renvoi si pas de ack), bufferisation des paquets "en avance"... etc...

TCP c'est du "open and don't care", particulièrement adapté à la transmission de fichiers. Le programmeur n'a rien a faire, sauf gérer la connection.

Pour tester UDP, il faut impérativement un "proxy UDP" (un programme qui renvoit vers un serveur/port donné tout ce qu'il recoit sur un port), éventuellement "defaillant" (qui de temps en temps simule une mauvaise connection).
Si tu utilises l'interface de loopback, alors les paquets arriveront toujours, et toujours dans le même ordre ! Ca ne sert a rien, c'est comme écrire un unit-test pour vérifier que 2+2 == 4 !

Pour tester TCP, on peut parfaitement utiliser l'interface de loopback (puisque c'est justement la couche en dessous qui gère les données), a condition de bien simuler des 'pertes' de connection intempestive.