Discussion :

[whoeao]

Bonsoir,

J'ai plusieurs blocs de données (<= 2ko) à écrire dans différents fichiers. En fait il s'agit de données transférées via winsocks. Il n'y a aucun problème en rapport avec les transferts, mais je rencontre un problème lors de la reconstruction des fichiers émis du serveur vers le client, et je pense que ce problème sera rencontré à chaque utilisation de write (même au niveau du serveur donc) si le soucis est en lien avec la taille des flux à écrire.

Aujourd'hui j'ai testé l'écriture de 7 fichiers transférés du serveur vers le client. Pour l'écriture j'utilise write() de ofstream. La taille des fichiers variait de 0 à 171 ko pour mon test. J'ai constaté que plus des données arrivent, moins l'écriture est efficace. En diminuant le nombre de fichiers (3 par exemple dans le cas d'un test ultérieur), je parviens à reconstruire les fichiers qui n'avaient pas été reconstruits lors de précédents tests.

Je m'y prend de la manière suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
// J'ai récupéré le nom du fichier dans un char[]
ofstream fichierEcriture;
fichierEcriture.open(nomFichier, ios::out | ios::binary);
 
/* Je boucle sur la réception des blocs de données. A chaque fois que je reçois un bloc de donnée, je l'écris dans le fichier fichierEcriture : */
fichierEcriture.write(buffer, taille); // Le contenu de buffer est valide !
 
/* Une fois que la taille du fichier reconstitué est égale à la taille du fichier de même nom présent sur le serveur, je ferme le flux */
fichierEcriture.close();

J'ai lu sur la toile que mon soucis pourrait provenir du fait que les données sont "trop" volumineuses et qu'il faudrait mettre à jour le flux en utilisant flush(). J'ai donc testé l'utilisation de flush() après chaque écriture de bloc et avant d'appeler close(), mais cela n'a rien changé. Je m'inquiète un peu puisque le but est de pouvoir transférer des fichiers bien plus volumineux que ceux utilisés actuellement pour mes tests.

Qu'en pensez-vous ?
Peut-être saurez vous ce qui ne va pas ?

Je peux mettre le code de mon application mais il n'y a pas plus d'indices que ce que j'ai déjà mis dans les balises code.

Merci par avance.

[LittleWhite]

Bonjour,

Ce morceau de code donne l'impression que vous fermez et ouvrez le fichier à chaque écriture ( ou réception de donnée ).Bizarrement, si pour un, fichier un peu plus gros, vous recevez deux paquets au lieu de un, et comme votre mode d'ouverture n'est pas un 'append' ( ajout ) et bah, vous écrasez les données du paquet 1 avec ceux du paquet 2.

Il faudrait ouvrir le fichier qu'une seule fois ( et envoie un message comme quoi c'est fini ( c'est une possibilité, y en a d'autre ) pour pouvoir le fermer correctement.

[whoeao]

Bonjour,

Je n'ouvre qu'une seule fois le fichier : avant la réception du premier bloc. Je ferme le fichier une fois que j'ai reçu toutes les données, donc il n'y a bien qu'une seule ouverture et qu'une seule fermeture.
Il n'y a pas d'écrasement de données puisqu'à la fin du travail de reconstitution, les fichiers qui devaient être reconstitués ont une taille égale à 0. Cependant, certains fichiers sont bien réécrits. J'ai l'impression que le taux d'erreurs est lié à la taille des données. Peut-être qu'il y a des engorgements... (mais je ne sais pas où).

[3DArchi]

Salut,
Je ne vois pas de raison qui ferait que l'écriture ne se fasse pas, les fichiers ne devraient pas avoir une taille de 0 . A moins d'avoir une erreur ailleurs...
Je comprendrais un ralentissement si la réception des blocs du réseau est plus rapide que l'écriture sur disque (...). Tout au plus, peux-tu essayer de découper en 2 thread : un qui reçoit les paquets du réseau et les mets dans une file, un second qui s'occupe d'écrire ces paquets sur le disque.

[whoeao]

Pendant l'écriture des données reçues dans les bons fichiers via les flux fstream, j'écris le contenu de mon buffer dans un fichier avec fprintf() et je vois bien que le contenu est écrit dedans.
Par exemple si je dois recevoir le fichier toto, je le reconstruis avec write(à (utilisation des fstream) et juste avant ça, j'écris dans un fichier, par exemple test_recv.txt, en utilisant fprintf() et là j'ai bien quelque chose qui s'écrit et je ne sais vraiment pas pourquoi ça ne fonctionne pas avec les fstream...
Je précise que le contenu du buffer n'est pas effacé, j'ai simplement le sentiment que write() n'écrit rien.

[whoeao]

Je comprendrais un ralentissement si la réception des blocs du réseau est plus rapide que l'écriture sur disque (...).

Les points de suspension indiquent que tu n'en es pas convaincu ?
Si tout ça se tient, pourquoi le fait que la réception des blocs soit plus rapide que l'écriture sur disque puisse faire que les données sont perdues ?

[3DArchi]

Les points de suspension indiquent que tu n'en es pas convaincu ?

Pas trop effectivement. Mais au cas où je vérifierais à ta place.

Si tout ça se tient, pourquoi le fait que la réception des blocs soit plus rapide que l'écriture sur disque puisse faire que les données sont perdues ?

Si tu utilises le même buffer pour la réception et l'écriture on pourrais imaginer un conflit. Mais, même ça je n'y crois pas trop. L'O.S fait, en général, une recopie vers un buffer interne avant le retour de la fonction. En tout cas, comme précédent, à vérifier.

La piste qui me vient de prime abord pour que ton écriture se passe mal serait un conflit entre plusieurs threads utilisant les mêmes stream et aboutissant à une race condition. As-tu plusieurs thread ?