Transfert de fichier TCP

remidub Messages postés 7 Date d'inscription samedi 22 mars 2003 Statut Membre Dernière intervention 8 juillet 2004 - 8 juil. 2004 à 14:31
cs_aardman Messages postés 1905 Date d'inscription mercredi 22 janvier 2003 Statut Membre Dernière intervention 17 septembre 2012 - 20 sept. 2004 à 17:17
Bonjour,

Je développe actuellement un logiciel qui nécessite des transferts de fichiers par TCP.
En effet, je décompose les fichiers en petits paquets (actuellement 512 octets) et je les envoie 1 par 1 du serveur vers le client.
Cependant un bug apparaît sur des postes sous win98, j'ai analysé les paquets avec ethereal pour comprendre ce qui se passait, et j'ai constaté que les paquets reçus ne correspondent pas aux paquets envoyés : certains paquets sont regroupés en un seul ... :(

J'ai résolu le problème en mettant une courte pause entre chaque réception de paquet (200ms) ... Mais bon c'est pas très propre comme méthode, enfin je trouve ...

Quelqu'un a t'il déjà été confronté à ce problème ? et si oui a t'il trouvé une solution ?

Merci d'avance !

PS: D'après les nombreux tests que j'ai effectué, les problèmes viennent bien du client et pas du serveur.

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
8 juil. 2004 à 17:28
Salut,
C'est normal, car tcp est un protocol dit "connecté".
Rien ne garanti que 1 send = 1 recv. Si tu veux cela, il faut utiliser le protocol UDP (moins fiable mais plus rapide).

Cependant je ne vois pas ou est le probleme, tout ce que tu recois, tu l'écrit directement dans un fichier. Le fait de recevoir et d'écrire 2 paquets a la suite ne change rien au fichier final non ?
0
cs_aardman Messages postés 1905 Date d'inscription mercredi 22 janvier 2003 Statut Membre Dernière intervention 17 septembre 2012 3
8 juil. 2004 à 17:34
Autre chose, pour obtenir de meilleures performances, il vaut mieux envoyer des gros "paquets" plutot que des petits. N'hésite pas a utiliser un buffer de plusieurs Ko..
0
cs_macros Messages postés 9 Date d'inscription mercredi 17 mars 2004 Statut Membre Dernière intervention 3 janvier 2005
20 sept. 2004 à 15:28
Salut a tous

En fait moi j'ai le meme problemes mais en pire...
C a dire que j'ai mis la longueur des paquets devant ces derniers mais lorsque je les reçoit j'ai un erreur : La longueur totale de la chaines recu ne correspond pas a la somme des longueurs des trames.

Et la je seche

Merci
0
cs_aardman Messages postés 1905 Date d'inscription mercredi 22 janvier 2003 Statut Membre Dernière intervention 17 septembre 2012 3
20 sept. 2004 à 15:35
Salut,
Comment as tu ouvert le fichier ? comment le lis tu ? comment l'envoie tu ?
bref sans code c'est dur de trouver l'erreur.
0

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

Posez votre question
cs_macros Messages postés 9 Date d'inscription mercredi 17 mars 2004 Statut Membre Dernière intervention 3 janvier 2005
20 sept. 2004 à 17:11
Ok :

Le programme est un client serveur
Les trames sont envoyé du serveur au client en UDP mais en cas d'erreur ( toutes les trames sont numeroté) je renvois les trames en TCP (eh oui j'utilise les 2 protocoles en memes temps) et c la qu'il ya problemes.

Chaque trames envoyé (en TCP) est en plus d'etre numeroté j'ajoute la taille a celle ci pour eviter de confondre 2 trames.Mais la taille totales de la chaine lut sur la socket est différentes de la somme des trames.

J'utilise la fonction select() pour savoir si mes sockets sont remplis ou non. Et je pense qu lorsque la 1ere trame arrive elle fait en sorte que la socket doit etre lut et je la lis pendant que d'autre trames arrive et je coupe donc certaine trames.

Comment faire pour etre sur que la derniere trame arrivé est bien celle lut...
0
cs_aardman Messages postés 1905 Date d'inscription mercredi 22 janvier 2003 Statut Membre Dernière intervention 17 septembre 2012 3
20 sept. 2004 à 17:17
Salut,
ben je suis désolé mais je ne peux pas t'aider, tu n'a répondu a aucune de mes 3 questions et tu n'a pas mis un seul bout de code...
0
Rejoignez-nous