Discussion :

[bcaro]

Bonjour à tous, je travaille en ce moment à un projet dans le cadre de mes études. Mes camarades et moi avons implémenter un réseau qui propose aux utilisateurs de télécharger des fichiers du serveur (et l'upload de leur fichier sur le serveur). Pour l'envoi de fichier large, il me semble qu'il vaudrait mieux les découper affin d'empecher le bloquage de l'envoie/réception sur les sockets de nouveau messages pour l'utilisateur.

Nous travaillons sur des systèmes Ubuntu ; pour faire simple, notre serveur cré pour tout nouvel utilisateur un processus (via un fork) qui va gérer les les envois des messages en provenance de cet utilisateur (transmission des requètes de l'utilisateur au bon processus de gestion, un par 'service' rendu par le serveur) et la réception de message (les 'réponses' des différents processus de gestion).

Le téléchargement étant l'un des services rendu par le serveur, je voudrais connaitre votre avis à tous quand à la meilleur stratégie à adopter pour gérer ce service. Une possbilité serait de 'pré-couper' les fichiers et de les envoyer les uns après les autres. Autre problème : les send/recv ne fonctionnent qu'avec des string (char*), suis-je donc obligé de transformer mes fichier en string et de les découper 'à l'avance' en paquet affin de les envoyer au utilisateur le quand ils le désirent, qui de leur coté devrons être capable de les coller et de les rentransformer en leur format originel... ?

Toute aide sera le bienvenu, merci d'avance
jeancparis@hotmail.com

[zais_ethael]

Les send/recv n'utilisent pas de chaines de caractères, mais des octets. Il se trouve juste que le mot clé assimilé aux octets en C c'est char
Ensuite, on dirait que tu va stocker bien des données avec ton prédécoupage. Pourquoi en as tu tant besoin? Soit M la taille de ton buffer, tu ouvres ton fichier en binaire, charges M octets dans le buffer, envoies les M octets puis tu recommences. C'est pas plus compliqué que ça.

[bcaro]

je pensais (pour je ne sais quelle raison) qu'on ne pouvait envoyer que des strings...
Pas de découpage nécessaire ; on pense créer alors un nouveau socket pour le téléchargement affin de ne pas bloquer les autres send/recv
Cette logique te semble correcte ?

merci pour ton aide

[zais_ethael]

Si tu commences à créer de nouvelles sockets sur d'autres ports, ça va faire bizarre et poser des problèmes. Quand une socket type serveur reçoit une demande de connexion, elle crée immédiatement une socket type client pour dialoguer avec le client, il suffit alors de passer cette nouvelle socket à un thread dédié au client puis le thread en cours reprend son attente de nouveaux clients.
Par contre, si vous utilisez du multi processus, je ne suis pas sur qu'on puisse faire passer un descripteur de socket d'un processus à l'autre, tu vas peut-être être dans l'obligation de l'ouvrir ton nouveau port (ou alors tu fais un serveur mono-connexion, ça dépend de ce que ton prof te demande ), mais ça ferait vraiment pas clean, faudrait ouvrir un port aléatoire sur ta machine et tu aurais vite un truc ingérable - bref on fait jamais comme ça en pratique.

[bcaro]

Comme je t'avais expliqué plus tôt, pour chaque nouvel utilisateur accepté, le serveur cré un nouveau processus. On pense donc que, lors d'une demande de téléchargement acceptée par le serveur, envoyer un message à l'utilisateur, lui demandent d'établire une nouvelle connexion. Cette connexion sera accepté comme précédamment et un nouveau processus sera donc créé. Ce dernier ne servira qu'à transmettre le fichier à l'utilisateur.
Cette manière te parrait-elle propre ?

merci d'avance

[zais_ethael]

Ben non justement, comme je te dis ça va créer un grand nombre de sockets type serveur ce qu'on ne fait jamais (le pire cas est celui de ftp qui en utilise 2, et c'est déja réputé pas pratique à administrer dans les firewall). La meilleure solution serait d'utiliser des threads (je crois vraiment que deux processus ne peuvent pas s'échanger de descripteur de socket, ça doit être comme pour les fichiers).
Bon, si c'est un petit dossier pour l'école je dis pas mais si c'est pour un vrai programme c'est mauvais.