Reprise du message précédent :

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

 
tout a fait.
 
et c'est le meme principe pour la voix (si le paquet se perd, ca sert a rien de le recevoir 2sec plus tard...   )

Est-ce qu'en udp on a la garantie qu'un paquet est entier et intact quand il arrive?

oui

 
Cela dit l'unité d'information que tu souhaites transmettre sera plus que probablement découpé au niveau de la couche 4 donc meme si le résultat d'un paquet est garanti tu n'est pas sur de récupérer ton unité d'info à l'autre bout.
 
Si tu transmets de l'AU par exemple et bien le fait de perdre un paquet va résulter d'une perte minime dans le son. C'est tout à fait acceptable et c'est comme ca que les systèmes de téléphonies sont implémentés (avec des mécanismes supplémentaires comme RTP)

Moi, j'ai fait un stage dont le sujet ressemble à ton projet (c'était pour Airbus)
 
des périphs (sans intelligence) en usb ou RS232 étaient connectés directement à un serveur (via des hub usb ou des ports rs232) et ce pc formatait les trames provenant des périphs en trames interprétables par un autre pc (simulateur contenant l'IA des périphs). Ces trames étaient envoyées du serveur au simulateur via de l'ethernet (TCP/IP). Voilà

C pas que je veux semer l'embrouille, mais l'IP aussi est un protocole de transport, ca vaut koi ?  

c'est un peu plus pratique à utiliser que le 802.3
 
 
 

 
eternet et ton cable réseau aussi alors. Si ca t'amuse tu peux travailler en couche 1 et écrire les signaux binaires directement sur l'interface réseau

un autre avantage de l'UDP si tu a plusieurs machines qui doivent communiquer et qu'elles sont sur un reseau local c'est le Broadcast.
 
Il y a un tres bon bus logiciel qui s'apple Ivy, developpé par le CENA, et dont les sources sont fourni en C, Java, Perl et Python. Ca pourrait peut etre t'aider.

Une petite chose de plus sur le protocole UDP :
 
Si une machine A "bombarde" le reseau; autrement dit elle envoie intensivement des donnees a une machine B. Or B est tres lente et a d'autre calcul tres importants et surtout tres long a faire.B ne va donc pas pouvoir tout lire de ce que A envoie. Comment le protocole UDP gere - t - il cela :
1 - A envoie en masse des donnees et B recupere ce qui peut (ex : A envoie les donnees 1,2,3,4,5 ; B recupere seulement le 1,3,5)
2 - Le reseau "sature", les donnees ne sont pas recuperees alors probleme de rezo
3 - A ralentit et s'adapte a la vitesse de B
 
Soit le cas 1 s'applique et aucun pb se passe (c le cas que je veux). Le cas 2 jve pas . Le cas 3 pkoi pas
 
Bref eclairez sur comment ca fonctionne tout ca  

Normalement c'est 1, mais si le réseaux est utilisé par beaucoup beaucoup de monde avec des gros trafics, çà peux aller vers 2. Tout dépend de ton réseau. Il peut par exemple être utile de réserver de la bande passante pour ton application.
Le plus sûr serait un réseaux dédié qui peut être facile à mettre en place si les machines sont proches.
 
Le cas 3 n'est pas géré en UDP. "A" ne sait pas ce que "B" reçoi.
Tu peut toujours le faire toi même. Par exemple "B" renvoie ce qu'il reçoi de manière à en informer "A", mais çà revient à peu de chose près à simuler du TCP avec des problèmes du genre "un paquet envoyé par 'B' mais non reçu par 'A' et la transmission s'arrête".
 
Comment est organisé ton réseau ?
"A" a-t-il besoin de communiquer avec d'autres machines que "B" ?
"A" et "B" sont-ils(elles ) proches ?

en fait c un rezo on ne peut plus simple ! Une grosse machine (B) recoit via ethernet 100Mbits les donnees de A. Seules c 2 machines st en rezo et proche l'1 de l'autre. De A vers B, seuls des chiffres sont envoyes (par lecture d'un fichier) et fourni tout pret pour B. B ne pourra dc lire que kk chiffre et a partir de ceux-ci , faire un autre calcul. Le resultat de ce calcul + les chiffres qui ont permit ce calcul st renvoye a A.
la connexion de A vers B est "sans" importance (B recevra ce qu'il peut). A l'inverse, B vers A est ULTRA important et toutes les donnees doivent arrivees ! dc j'utilise UDP (vitesse, securite absolument non necessaire) pour comm de A vers B et TCP pour comm de B vers A. Voila
 
Bon si tu dis que c le cas 1 pour A vers B en UDP qui est applique, je n'ai dc pas a me soucier des donnees envoyer : je me chargerai juste de lire le fichier et de bazarder tout ca sur le reseau. Merci

Dès l'instant où tu ouvre une connexion TCP, autant que tu l'utilise dans les 2 sens

 
   
 
t a été le chercher loins celui la

J'aime bien ce smiley mais c'est pas toujours évident de le sortir.  
Alors pas question de rater une telle occasion

 
 
on dirait qu'il dance cet imbecile

Encore un autre truc, qu'est ce qui est/peut etre utilise pour le protocole de transport ethernet en plus de TCP/UDP ? (je dois justifier mon choix, donc je me dois d'identifier "chaque" protocole, du moins les plus utilises ... je pensais a SNMP)

euh, snmp c'est une couche au dessus, hein

 
Ha ok  

A combien peut-on estimer le pourcentage de perte de paquet par UDP (plutot fort/faible/moyen)...et donc le pourcentage de renvoie d'un paquet par TCP ?

 
bin ca dépend du réseau. La plupart du temps une perte de paquet est due à une congestion dans un des noeuds (i.e. routeur ou entrée de subnet). Donc y a pas de pourcentage dans l'absolu. Si tes deux machines sont sur un LAN elle est très faible
 
Edit: je ne vois pas vraiment où tu veux en venir au juste. Quels critères utilse tu pour prendre ta "décision"?

 
Ben si le % aurait e t fort, j'orais eu trop de packets perdu et ds ce cas la, j'utiliserais TCP ... mais bon si c pas quantifiable  

As tu regardé Ivy? Ca te simplifirait la vie
 
http://www.tls.cena.fr/products/ivy/
 

 
dans l'absolu certainement pas. Y aurait pas autant de recherche de QoS sinon

Voila, j'utilise la fonction sendto de VC++6 pour envoyer les packets de prototype :
 

 
Le bleme c que moi mon buffer (const char FAR * buf) qui pointe sur les donnees a envoyer, pointe sur un long. Ce sont bien des chiffres que je dois envoyer pas des char . Vous feriez comment ?

 
Ca mérite un topic séparé avec un titre clair

Tu t'en fous si c'est des int ou des chars. Le tout c'est de faire un cast correct. Cette fonction n'a pas été prévue pour n'envoyer que des chaines de caracteres! Le type char* est ici juste un moyen simple de dire pointeur vers des données. Et si on a pris char et pas int, c'est parce qu'un char fait 1 octet, et donc que tu peux accéder a l'octet que tu veux facilement puisque tu as un tableau.
 
edit : je t'encourage vivement, si tu as d'autres questions, a faire un nouveau topic