Bonjour à tous,

Il y a quelque chose qui m'est encore très mystérieux en rapport avec la réception de données et je suis d'ailleurs confronté à un problème à ce niveau, alors j'apprécierais avoir quelques explications.

Je travaille sur la réception de fichiers et je dispose d'une structure d'entête pour connaître la taille des données à recevoir. En ce moment, je planche sur un problème d'erreur socket (code 10055) et donc je ne comprends pas vraiment comment tout est géré niveau système en fait.
Le serveur envoie un nombre n de fichiers (j'ai défini un protocole d'envoi) et tout semble aller de ce côté. Le processus client pour la réception suit le même protocole (petite précision : j'utilise le protocole TCP-IP donc tout est ordonné).
J'imagine que le serveur se fiche de savoir comment est gérée la réception et qu'il se contente d'envoyer les paquets, mais voilà, là, ça plante ! Le client qui reçoit les données crash au bout d'un certain nombre d'appels à recv() et l'erreur socket rencontrée me laisse penser que le buffer système est engorgé par les paquets, mais est-ce vraiment le fond du problème ?

Ca plante plus particulièrement lorsque je reçois les blocs de données qui constituent les fichiers du serveur. Pourtant, jusqu'au moment auquel survient l'erreur, tout ce qui est récupéré est testé est écrit, alors j'aimerais savoir à quel moment le buffer système libère des ressources ? N'est-il pas censé être vidé au fur et à mesure que je récupère les données dans mon buffer logiciel ?

Je pense que le problème peut provenir du fait que j'examine mal les points-clés du code. En effet, j'utilise des MessageBox() pour contrôler la réception de chacun des fichiers et donc ça peut bloquer la réception du fichier n+1, pendant que le serveur continue à envoyer des données. Du coup je peux comprendre cet engorgement.

Mon soucis majeur est que, si je ne mets plus aucun contrôle (suppression des MessageBox()) pas grand chose ne va : certains fichiers sont bien transferés et d'autres non, parfois ça crache avant la fin du processus de réception, tout est fonction du nombre de fichiers à recevoir en fait.
Il n'y aurait pas un moyen de pouvoir rendre tout ça plus propre, plus fiable ?
J'ai pensé à envoyer un message depuis le client vers le serveur pour lui indiquer que j'ai bien reçu un bloc après chaque réception mais ça me semble assez paradoxal puisqu'à mon avis un problème de "transfert" ne se résout pas avec d'autres transferts...

Y a t-il un moyen de connaître la taille des ressources occupées dans le buffer système de ma socket de réception ?

J'ai tenté d'utiliser setsockopt() pour modifier en l'augmentant la taille maximale du buffer système mais ceci reste approximatif et pas forcément une solution de choc, non ?

Pour que vous y voyez un peu plus clair, je procède comme ceci :

Côté serveur :
(en pseudo-code)
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
 
// Il y a n fichiers à envoyer :
 
TQ nombre de fichiers envoyés < nombre de fichiers à envoyer
 
          Envoyer tailleFichier
          Envoyer nomFichier
          TQ nombreOctetsEnvoyes < nombreOctetsAEnvoyer // boucle d'envoi des blocs de données)
                 Envoyer bloc de données
                 nombreOctetsEnvoyes = taille du bloc
          FTQ
FTQ
Je précise qu'avant chaque envoi, j'envoie l'entête et du coup, le nombre de recv côté client est égal au nombre de send côté serveur. Je tiens à préciser que je teste toujours la valeur de retour des fonctions sockets.

Comment s'y prendre pour que tout soit fiable, peu importe le nombre de fichiers à transférer, leurs tailles respectives, etc. ?

Merci par avance !