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.