Discussion :

[theawe]

Bonjour,

Je suis en train de développer un " serveur " d'envois multiples de fichiers. Ces derniers sont soit binaires, soit textes. Ce détail est important pour le client puisque en réception, je n'utilise pas les mêmes méthodes d'écritures dans mes fichiers.
J'ai une boucle du côté client qui reçoit les messages spécifiant le type du fichier. Elle ne s'arrête seulement lorsque le nombre de fichiers effectivement reçus est égal au nombre de fichiers à recevoir.
J'ai constaté que, si dans la boucle du côté client il y a plus d'instruction que dans celle du côté serveur, la fonction recv() reçoit plusieurs messages envoyés par send().

Voici un exemple :
Je dispose de quatre fichiers : txt, bin, bin, txt dans cet ordre précis.
Si je fais simplement un envoi via send() côté serveur et une réception via recv() côté client, et que j'écris le contenu du buffer de réception dans un fichier à chaque tour de boucle, j'obtiens : txt, bin, bin, txt. En d'autres termes des messages corrects.
Si je mets plus d'instructions dans ma boucle côté client, je ne reçois que deux messages : txt, binbintxt.
J'ai utilisé des Sleep() côté serveur pour voir j'avais un problème de temps. Le résultat a été concluant, je reçois à nouveau txt, bin, bin, txt.

Il doit y avoir une autre solution, plus rapide, non ?

[ram-0000]

Ce fonctionnement est normal (même s'il est perturbant).

Pour 1 send(), il est parfois nécessaire d'avoir plusieurs recv()
Pour plusieurs send(), il peut arriver qu'un seul recv() soit suffisant.

Il ne doit pas exister dans ton code de lien entre le nombre de send() et le nombre de recv() et tu n'as pas le droit de dire 1 send() = 1 recv().

Pour pallier ce problème, il y a deux techniques :

• Soit l'émetteur envoie la longueur des données puis les données elles mêmes. Ainsi, le récepteur lit la longueur et sait combien il va recevoir de données ensuite. Cette technique est plutôt utilisée pour les protocoles orientés binaire (comprendre, qui envoie des données dont les valeurs des octets peuvent aller entre 0 et 255 sans aucune contraintes)
• Soit les données sont délimitées/terminées par un caractère spécial (genre retour chariot ou code ascii 0). Cette technique est plutôt utilisée par les protocoles orientés texte (comprendre qui envoient du texte en clair, en ASCII)

[Mac LAK]

Ce fonctionnement est normal (même s'il est perturbant).

Pour 1 send(), il est parfois nécessaire d'avoir plusieurs recv()
Pour plusieurs send(), il peut arriver qu'un seul recv() soit suffisant.

Enfin... Normal en TCP/IP : si l'on passe en UDP/IP, on a bien du "un pour un"... Enfin, si le datagramme arrive à destination, du moins !!

Ceci étant dit, vu que 99% des gens utilisent du TCP/IP pour leurs communications (et que c'est vraiment pas une mauvaise idée d'ailleurs), autant prendre l'habitude de ne pas penser en terme de "nombre" d'appels à send / recv, mais bel et bien en octets transférés.

[ram-0000]

Je parlais effectivement d'un protocole TCP

Enfin... Normal en TCP/IP : si l'on passe en UDP/IP, on a bien du "un pour un"... Enfin, si le datagramme arrive à destination, du moins !!

pour UDP, tu as bien résumé la situation !

[Mac LAK]

pour UDP, tu as bien résumé la situation !

Yep : "Pas de garantie de livraison en UDP, ni d'ordonnancement correct des trames à l'arrivée"...
Alors que TCP garantit, lui, la livraison des données ainsi que l'ordre... Et "coûte" le fait que la réception n'est pas toujours synchrone avec l'émission en terme de nombre d'appels et/ou de taille des blocs reçus.

[theawe]

C'est assez dommage. Cela me pose un problème d'algorithmie me semble t-il. En fait, voici ce se passe et ce qui devrait, par la suite, se passer :

Une application, qui jouera le rôle du client, a pour but d'interpréter le contenu d'un fichier texte. Lorsque le contenu du document a été interprété, plusieurs fichiers sont générés : 0 à n fichiers binaires ET 0 à n fichiers textes.

J'ai développé une application serveur qui elle fait ce travail là à partir du fichier que le client lui a envoyé. Les fichiers générés le sont donc dans un dossier dépendant du serveur. Une fois ce traitement effectué, le serveur doit renvoyer au client tous les fichiers générés. Je dois donc préciser plusieurs choses au client :

- 1) Le nombre de fichiers qu'il doit recevoir.
- 2) Pour chacun des fichiers générés, son nom, sa taille et s'il s'agît d'un fichier binaire ou texte.

Côté client, je dois conditionner ma réception en fonction du type de fichier.
Bref, je vais réfléchir à mon algorithme pour que cela fonctionne.

Le problème c'est que si je dois envoyer la taille des données à transférer au client, je vais également être confronté à ce problème d'inéquivalence.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Tant Que (nbFichiersRecv < nbFichiersARecevoir)
          recevoir informations // Taille (octets) + Nom + type
          Si type = bin
                    nbOctetRecv <- 0
                    ouvrir fichier
                    Tant Que (nbOctetRecv < Taille)
                              nbOctetRecv <- nbOctetRecv + recevoir données
                              Ecrire données dans le fichier Nom
                    Fin Tant Que
                    fermer fichier
          Fin Si
etc...

Fin Tant Que

Le problème c'est qu'au moment de la réception des informations, je ne recevrai pas correctement ce qui est envoyé.