Application Client/Serveur TCP/IP: pertes de trames

LaTatadu91 Messages postés 968 Date d'inscription jeudi 20 mai 2004 Statut Membre Dernière intervention 26 avril 2013 - 25 janv. 2010 à 15:39
LaTatadu91 Messages postés 968 Date d'inscription jeudi 20 mai 2004 Statut Membre Dernière intervention 26 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)

Merci d'avance,


 

6 réponses

cs_aardman Messages postés 1905 Date d'inscription mercredi 22 janvier 2003 Statut Membre Dernière intervention 17 septembre 2012 3
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.
0
LaTatadu91 Messages postés 968 Date d'inscription jeudi 20 mai 2004 Statut Membre Dernière intervention 26 avril 2013 1
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à...)


 
0
cs_aardman Messages postés 1905 Date d'inscription mercredi 22 janvier 2003 Statut Membre Dernière intervention 17 septembre 2012 3
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.
0
LaTatadu91 Messages postés 968 Date d'inscription jeudi 20 mai 2004 Statut Membre Dernière intervention 26 avril 2013 1
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!


 
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
cs_aardman Messages postés 1905 Date d'inscription mercredi 22 janvier 2003 Statut Membre Dernière intervention 17 septembre 2012 3
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).
0
LaTatadu91 Messages postés 968 Date d'inscription jeudi 20 mai 2004 Statut Membre Dernière intervention 26 avril 2013 1
25 janv. 2010 à 22:54
Ouais c'est une piste à suivre!
merci des conseils, je vais tacher de programmer un peu plus profondément pour pallier à ces soucis!


 
0
Rejoignez-nous