Application Client/Serveur TCP/IP: pertes de trames
LaTatadu91
Messages postés968Date d'inscriptionjeudi 20 mai 2004StatutMembreDernière intervention26 avril 2013
-
25 janv. 2010 à 15:39
LaTatadu91
Messages postés968Date d'inscriptionjeudi 20 mai 2004StatutMembreDernière intervention26 avril 2013
-
25 janv. 2010 à 22:54
Bonjour,
Je développe actuellement une application multithread en C++ sous Visual Studio 2005.
Ce programme a pour but d'effectuer des calculs cycliquement et est dépendant de trames TCP/IP reçues d'un autre PC.
j'ai donc un thread dédié à cette communication TCP/IP (dans laquelle je suis client)
et un thread dédié aux différents calculs et rapports...(il est à noté que ces calculs peuvent prendre beaucoup de mémoire CPU et donc de temps)
En marche normale je reçois des trames TCP/IP que je décompose (par exemple : identifiant message sur 2 caractères+ data1 sur 4 + data2 +...) et ainsi de suite.
Le problème que je rencontre actuellement est que :par moment je reçois une trame qui se décompose incorrectement : comme si je n'avais pas reçu le début du message (l'identifiant)
du coup le message est perdu!
donc ma supposition est que le thread de calcul bloque mon application et donc par moment je ne reçois plus correctement mes trames....
je ne sais pas quoi faire, car en cours j'ai appris que les trames TCP/IP sont normalement envoyées et contrôlées donc aucune perte possible...
j'espère avoir bien décrit mon problème, et que quelqu'un saura ce qu'il est possible de faire.
résumé : mon application multithread
thread 1 : Calcul --> tourne indéfiniment --> lance des fonctions de rapports .txt ou SQL
thread 2: TCP/IP --> Recv--> décomposition de message --> suivant le cas Send --> lancement de calculs (plus ou moins long) puis retour à Recv etc..... (boucle infinie)
cs_aardman
Messages postés1905Date d'inscriptionmercredi 22 janvier 2003StatutMembreDernière intervention17 septembre 20123 25 janv. 2010 à 18:13
Salut,
En effet, aucune perte possible en tcp, mais ça ne signifie pas pour autant qu'un send coté client correspondra à un recv coté serveur, c'est a mon avis la que se situe ton problème. tu utilises le mot trame comme s'il s'agissait du mot datagram comme en udp, alors que ce n'est pas le cas.
LaTatadu91
Messages postés968Date d'inscriptionjeudi 20 mai 2004StatutMembreDernière intervention26 avril 20131 25 janv. 2010 à 18:20
Oui je pense parfois mal utilisé certains termes technique, justement comment être sur de faire correspondre un send à un recv?
si par exemple je me fais bombarder de 200 messages/minutes? (j'exagère là...)
cs_aardman
Messages postés1905Date d'inscriptionmercredi 22 janvier 2003StatutMembreDernière intervention17 septembre 20123 25 janv. 2010 à 19:43
Salut,
tu ne peux pas, c'est à toi de développer ton programme en tenant compte de ce comportement.
En général, deux techniques sont utilisées pour pouvoir recomposer les messages reçus:
- utiliser un séparateur entre les messages (typiquement, les protocoles qui contiennent des commandes ascii comme pop, smtp, http, ftp, irc, ...) utilisent la suite de caractère \r\n.
- préfixer ton message par sa taille: par exemple, le premier octet de ton message correspond à la taille des données qui suivent.
LaTatadu91
Messages postés968Date d'inscriptionjeudi 20 mai 2004StatutMembreDernière intervention26 avril 20131 25 janv. 2010 à 20:10
Oui, on peut utiliser un prefix correspondant à la taille du message, mais je ne vois pas en quoi cela va m'aider ...
concrètement ce qui arrive est :
normal: je reçois id-size-data1-data2-data3...
problème je reçois data1-data2-....
c'est comme si dans ma boucle , au moment de revenir au Recv, "j'arrivais trop tard" et du coup certains messages ou parties de message sont perdues!
Vous n’avez pas trouvé la réponse que vous recherchez ?
cs_aardman
Messages postés1905Date d'inscriptionmercredi 22 janvier 2003StatutMembreDernière intervention17 septembre 20123 25 janv. 2010 à 20:40
Salut,
tu l'a dis toi même: aucune perte n'est possible en tcp. ça veut donc dire que si tu recois data1-data2- lors d'un recv, c'est que tu as déja recu id-size- lors du recv précédent (surement collé a la fin du message précédent).