Discussion :

[fusionfroide]

Salut,

J'ai programmé une application serveur-client (1 serveur et 1 client seulement) pour un transfert des fichiers. Très vite je me suis aperçu qu'il faut créer un dialogue entre le serveur et le client pour synchroniser cette application sinon le client n'arrive plus à suivre le flux de données transféré par le serveur.

Serveur------------------Client

boucle while--------------boucle while
send(taille) ==========> recv(taille) (1)

recv(dialogue) <======= send(dialogue) (2)

send(données) =======> recv(données) (3)

Le recv() du coté serveur étant bloquante, me permet d'évite au client d'être débordé par 2 send() successifs. J'ai remarqué surtout que cette configuration fonctionne pour un petit nombre de fichiers. Dès qu'on commence à transférer une quantité importante de fichiers, tous ces recv() et send() ne sont plus synchronisés et le programme fait n'importe quoi. La seule solution que j'ai trouvé pour l'instant c'est d'insérer des fonctions comme sleep() ralentir la boucle coté serveur mais le cadre dans lequel cette application sera utilisée n'autorise pas ce genre de fonctions.

Y a il un moyen de garantir qu'une information envoyée par le send() au niveau (1) puisse être capter par le recv() du niveau (1) et de même pour les autres send() et recv() des deux autres niveaux ?

merci.

[Neckara]

Quel protocole utilises-tu?

Pour transférer des fichiers, tu peux utiliser du TCP, tu auras une garantie que les données reçues sont correcte, tu conserveras l'ordre des paquets, et tu ne devrais pas avoir de problèmes de synchronisations.

[fusionfroide]

Et pourtant c'est le protocole TCP/IP que j'utilise ... Je pense quand on utilise un send() pour un seul recv(), il n y a pas de problème. mais si on utilise plus fonction send() et recv() rien ne nous garantit qu'un send() arrive bien sur le bon recv() ! c'est delà que viens mon problème.

D'ailleur, il arrive qu'un recv() (celui dédié à intercepter le fichier) coté client intercepte un paquet de 1460 octets d'information utile (j'ai crée un buffer de 1460 octets pour les stocker) MAIS intercepte aussi le message (2 octets) servant au dialogue. Du coup ces octets supplémentaires ne pouvant pas aller dans le buffer qui est déjà plein, j'ai un segmentation fault !

Avec une fonction sleep, tout ces problèmes disparaissent mais je pense que c'est la preuve que les informations envoyées par plusieurs send() sont captées par un seul recv() (coté client) au lieu de deux recv().

[Neckara]

Et pourtant c'est le protocole TCP/IP que j'utilise ... Je pense quand on utilise un send() pour un seul recv(), il n y a pas de problème. mais si on utilise plus fonction send() et recv() rien ne nous garantit qu'un send() arrive bien sur le bon recv() ! c'est delà que viens mon problème.

TCP/IP garantie l'ordre des messages, tu es sûr que ce n'est pas un problème au niveau de ton code?

D'ailleur, il arrive qu'un recv() (celui dédié à intercepter le fichier) coté client intercepte un paquet de 1460 octets d'information utile (j'ai crée un buffer de 1460 octets pour les stocker) MAIS intercepte aussi le message (2 octets) servant au dialogue. Du coup ces octets supplémentaires ne pouvant pas aller dans le buffer qui est déjà plein, j'ai un segmentation fault !

Pour le "message servant au dialogue" , est-ce un message que tu envois toi-même ou est-ce que tu parles des messages envoyés par le protocole TCP/IP pour redéfinir la taille de la fenêtre et autre?

Avec une fonction sleep, tout ces problèmes disparaissent mais je pense que c'est la preuve que les informations envoyées par plusieurs send() sont captées par un seul recv() (coté client) au lieu de deux recv().

Ce serait quand même bizarre, l'envoie regroupé ou segmenté des paquets se fait à une couche plus basse que celle que tu utilises en faisant send() et recv() si je ne m'abuse.

Je pense que tu as un soucis au niveau du code.
Je ne sais plus si c'est la présence ou l'absence du '\0' à la fin du message à envoyer, mais on peut avoir des problèmes à cause de cela quand on utilise des pipes, peut-être est-ce aussi le cas avec send et revc?


EDIT : d'après mon oncle, avec le TCP/IP il faut que tu contrôle la longueur du paquet reçu. TCP ne garantirait pas la longueur du paquet reçu (il peut être plus petit si fragmentation ou plus grand si fusion des paquets).