Voila je dois concevoir une appli permettant la communication entre un simulateur et un serveur. Un ordinateur entre les deux doit se charger d'envoyer des donnees au serveur par protocole reseau. Que choisir : programmation TCP/IP ou bien UDP ?
eclaircicez moi sur les differences, la facilite d'implimentation en C++ (Visual C++)...
Merci

pas dur  
 
TCP protocole en mode connecté (stream) utile pour les applis qui ont besoin d etre en mode connecté (ex : client ftp)
 
UDP protocole en mode non connecté (datagram) ex : quake (tu peux rejoindre une partie en cours)
 
 
En gros pour utiliser ces protocoles sous windows tu utilises winsock2. tu auras l aide dans MSDN je ne vais pas te detailler tout.  
 
Juste un truc, apparemment toi, tu as besoin d un mode connecté donc TCP.
 

 
 

pas dur  
 
TCP protocole en mode connecté (stream) utile pour les applis qui ont besoin d etre en mode connecté (ex : client ftp)
 
UDP protocole en mode non connecté (datagram) ex : quake (tu peux rejoindre une partie en cours)
 
 
En gros pour utiliser ces protocoles sous windows tu utilises winsock2. tu auras l aide dans MSDN je ne vais pas te detailler tout.  
 
Juste un truc, apparemment toi, tu as besoin d un mode connecté donc TCP.
 

 
 

HS  
 
j ai enfin compris pourquoi y en avait qui avaient 2 posts identiques a la suite : en utilisant la touche (de merde) precedente du navigateur, ca rappelle le script de post et ca reposte.
 
 
Fait chier je deteste cette touche mais j ai pas d autre choix, je suis sur un mac (de merde aussi) et ca rame tellement pour rappeler les pages que je prefere faire precedent plutot que d attendre au moins 2 mn pour chaque page .
 
/HS

Dc tu penses que je dois utiliser TCP/IP a priori. En fait, plus exactement, il s'agit d'un simulateur qui comporte des capteurs. Ces derniers fournissent des informations que l'on recueille sur un PC intermediaire. Celui-ci fait a partir de ces donnees recues des calculs necessaires ; ainsi, les donnees sont pretes a etre envoyees (par protocole reseau (carte ethernet)) au serveur qui lui aura donc une tache allegee en recevant ainsi les donnees toutes pretes du PC intermediaire. Il s'agirait donc d'une simple communication classique. UDP ne suffit - il donc pas ?

ca m'étonnerait que le proto d'un jeu se base sur de l'UDP ...
et pkoi il faudrait de l'UDP pour pouvoir se connecter en cours de partie  

si tu considere que tu n as pas besoin d authentification et que tu veux juste "recevoir" des donnees d un client pour les  traiter ensuite, le mode UDP peut dans ce cas te satisfaire (parait que c plus rapide m'enfin)...
 
tu recevras des paquets venant de ton client et ton serveur devra les traiter.
 
Il me semble juste (par contre la c pas sur) que les paquets UDP n arrivent pas forcement dans l ordre (c est un truc qui fait partie du QoS de TCP) mais je ne sais plus si c est pour UDP ou carrement IP (parceque pour IP parcontre c sur)
 
regarde les RFC pour en etre sur (je regarde de mon coté)
 
 
 
Enfin tout ca pour dire que ce que tu veux implementer , t en auras pas pour longtemps ni beaucoup de code a pondre (enormement d exemples sur le net sur MSDN)
 
tiens pour te dire : j ai implementé un petit programme (3 jours) qui sert a relayer des ecritures port com a travers internet ... j ai utilisé le mode TCP mais effectivement j aurai pu utiliser UDP. C est juste parce que j ai pas l habitude de l utiliser (et il est moins utilisé d ailleurs)

pour UDP : l'ordre des paquets n'est aps assuré, ni le fait que tu les reçoives ...  
 
franchement, faire de l'UDP c'est vraiment se compliquer la tache !

 
merci de me confirmer ceci.
 
je pense qu il y a quand meme des interets a utiliser ce protocole , ne serait que pour la vitesse (ping ou transfert) , mais aussi  pour ne pas avoir a gerer de "session"

a part opur de l'optimisation, je vois pas l'intérêt
 
et vous la complexité (ordonancement des paquets, gestion des ressoumission, etc ...), faut vraiment avoir un sacré besoin de performance pour justifier de se faire chier avec ca.
 
par exemple, le proto HTTP qui est basé sur du "question-réponse" (mode déconnecté), ce qui correspond bien au modèle UDP, bha il utilise du TCP pour pas avoir à se faire chier avec tout ca ...
 
edit : et si tu veux pas gérer de session, bha tu fermes tes connexions et puis voilou ...

chui d accord avec toi ,si pas besoin de performances , alors vaut mieux utiliser TCP (plus simple etc...)
 
 
mais bon je suis persuadé que quake utilise UDP. c pas pour rien.

 
ca n'a RIEN à voir  

 
mais qu'est ce que tu racontes toi?

 
quake utilise UDP parce qu'il peut se permettre de perdre un peu de détails comparé à la latence si un paquet TCP était perdu. Avec TCP chaque paquet se doit d'etre délivré et dans un ordre correct. Si un paquet se perd dans le réseau par suite de congestion sur un noeud par exemple, il y aura une latence avant que l'émetteur ne s'en rende compte et retransmette. Cette latence est inadmisible pour un jeu en réseau.
 
Par contre perdre un ou deux paquets c'est pas bien grave, c'est pas comme si tu transmettais un document ou un mail par exemple.
 
Mais ca n'a rien a voir avec le fait que tu peux te connecter à une partie en cours

vous êtes sur que c'est de l'UDP quake ?

 
pour une partie du traffic je pense que c'est ce qu'il y a de plus raisonnable

Oui

http://www.doc.ic.ac.uk/~cjp99/mrq [...] node3.html
 
Edit: et ce lien résumé mon post précédent d'ailleurs

 
+1
 
En gros :  
- TCP : c'est le téléphone : avantage tu es sûr que quand tu envois qqchose, ça arrive. Tu peux avoir plusieurs téléphone (plusieurs connection)
- UDP : c'est la poste. Tu envois, ça peux ne pas arriver (grève ). Avantage très minime: c'est un poil plus rapide car celui qui reçoit ne transmet pas d'accusé
 
Edit : pour le temsp réel( Quake, serveur vidéo,..), on préfère utiliser UDP

Merci google ( quake network udp ) : http://www.alumni.caltech.edu/~chamness/qwPackets.html
 
Et aussi google (quake network tcp ) :
http://www.jfind.com/articles/glass033100.shtml

 
bon téléphone/poste c'est pas super comme image. Surtout qu'en téléphonie sur IP c'est clairement pas TCP qui est utilisé
 
(ok ok je fais ma pute désolé)

 
ok , de toutes facons ca n'etait que des suppositions... je me tairais la prochaine fois plutot que de raconter mes conneries  
 
merci pour tes eclaircissements. Juste une question, est ce que la plupart des jeux utilisent UDP ou c est specifique a peu de jeu comme quake ?

http://www.doc.ic.ac.uk/~cjp99/mrq [...] node3.html
T'as lu le titre ?

 
re autant pour moi  

 
la violence ne resoud rien

Et on peut même ajouter que ca arrive dans l'ordre où ca a été émis  
Alors qu'en UDP, rien n'empêche un paquet d'en doubler un autre

le fait que les paquets UDP n'arrivent pas dans l'ordre n'est pas du au fait qu'ils doivent traverser le "réseau" (chemins différents possibles pour deux paquets UDP) ?
 
si c'est en local, normalement les paquets étant envoyés dans l'ordre ils devraient arriver dans l'ordre non ? (sauf collision => perte du paquet)
 
 
 
je suis neuneu ! n'est-ce pas ?

Oui, en local, il y a de très fortes chances pour qu'ils arrivent dans l'ordre  
Mais ce n'est pas garanti, tu ne peux pas te baser sur cette hypothèse pour ton programme

En gros UDP : plus performant/rapide mais moins fiable
TCP : moins performant mais fiable
 
Pour mon cas j'utiliserai dc UDP
Bon OK merci a tous  

 
ah bon, tu peux te permettre de perdre des infos en route, pour économiser 2ko/s de bande passante en ethernet ??
 
prends du tcp, il est tellement plus adapté a ton utilisation!

 
Ben avt il ni avait pas de PC intermediaire (celui ci que je dois programmer) et ils utilisaient le protocole UDP (j'ai les sources) pour communiquer (entre serveur et simulateur) a croire qu'il ont fait un choix qu'ils jugeaient correct ...ou bien ils ont fait ca a la rache   . Il est vrai que ca depend de l'appli : je ne sais pas si on se doit d'avoir des communications hyper fiables . Il n'y a aucune personne pour me le dire  (aucun informaticien)

 
le probleme de savoir si tu as besoin de communications fiables n'est absolument pas informatique.
 
Si tu peux te permettre de perdre des infos de tes capteurs de temps en temps, alors tu PEUX utiliser udp.
 
je penses néanmoins que c'est se faire chier pour rien, il te suffit d'etablir une connection tcp vers ton serveur et de lui balancer les données.
 
Ca sera un tout ptit poil plus utilisateur de ressources que l'udp mais bien plus simple a programmer et tes communications seront sures

Y'a peut-être un facteur temps qui joue :
 
Si les capteurs envoient des infos à haute fréquence, l'utilisation de TCP peut alors poser un problème en introduisant un temps d'arrêt dans les comunication alors que les données continues d'arriver des capteurs.
 
S'il y a un rique d'engorgement TCP est à proscrire.
 
C'est sans doute une des raisons qui fait que les jeux en réseaux utilisent UDP.

UDP protocole en mode non connecté (datagram) ex : quake (tu peux rejoindre une partie en cours)
 
-> HalfLife il est en tcp ...
 
je dirais que l'udp il faut se taper la gestion des paquets, alors que le tcp, non. tout depend ce qu'on veut faire, mais une bonne gestion des paquets tcp peut se montrer meilleur qu'utiliser du tcp.

 
une guerre de retard. Ca a déjà été dit

 
ràv

UDP : protocole qui peut perdre des paquets. C'est là le principal interet pour les jeux. Typiquement, on parle ici des paquets de mise à jour de position qui ont cette tête là :
 
( au temps T0, l'objet O est à la position P )
 
Si tu perds le paquet et que TCP le renvoye 2 secondes plus tard, l'information fournie est dépassée de tt façon.

 
ca aussi ca a été dit. Vous lisez les topics un peu avant de répondre?