Discussion :

[whoeao]

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 !

[ram-0000]

Ton problème ressemble à une perte de synchronisation entre l'émetteur et le récepteur.

J'ai l'impression qu'il manque la longueur du nom du fichier ce qui fait que cela peut parfois désynchroniser.

Autre point, tes fichiers ont bien ouverts en mode binaire ?

[whoeao]

La longueur du nom du fichier est bien envoyée dans l'entête, juste avant la réception du nom lui-même.
J'ai testé tout un tas de choses aujourd'hui et j'en suis arrivé à la conclusion qu'il y a effectivement un problème de synchronisation. Le buffer système est engorgé et le timeout pour le vider n'est pas assez rapide. Je pense que je vais tester une solution à laquelle j'avais penser plus tôt : assurer au serveur qu'il peut envoyer un bloc qu'à partir du moment ou le client a traité le bloc précédent.

J'ouvre bien tous mes fichiers en mode binaire, oui.

Je vous tiens au jus !

[orfix]

...le nombre de recv côté client est égal au nombre de send côté serveur...

Attention, pour un send() il faut parfois (souvent même) plusieurs recv(). Souviens-toi que recv() retourne le nombre de bytes reçus.

[whoeao]

Attention, pour un send() il faut parfois (souvent même) plusieurs recv().

Même dans le cas où les sockets sont bloquantes et que pour chaque appel à recv() je sais exactement combien d'octets je dois recevoir ?

[orfix]

Même dans le cas où les sockets sont bloquantes et que pour chaque appel à recv() je sais exactement combien d'octets je dois recevoir ?

If no messages are available at the socket, the receive calls wait for a message to arrive, unless the socket is non-blocking (see fcntl(2)), in which case the value -1 is returned and the external variable errno set to EAGAIN. The receive calls normally return any data available, up to the requested amount, rather than waiting for receipt of the full amount requested.