Programmer une routine d'envoi de fichier...

Programmation d'applications complexes
popstatic
Messages : 83
Inscription : lun. 20/sept./2004 18:21
Localisation : derriere toi fais gaffe!

Programmer une routine d'envoi de fichier...

Message par popstatic »

....Qui ne charge pas l'intégralité du fichier en mémoire!

Bonjour à tous d'abord!

En fait j'ai repris une partie du code de Progi1984 (merci beaucoup d'ailleurs, cette base m'a été très utile -headers+mimes...-), pour réaliser de même un petit serveur http (rien de mieux que réinventer la roue pour faire rouler une voiture n'est ce pas?...^^).

Mon problème vous l'aurez deviné: l'envoi de gros fichiers (pour faire simple on va dire > 1Mo) pose des problèmes de mémoire vive si ma routine d'envoi des données charge intégralement le truc en mémoire..., surtout s'il y a plusieurs utilisateurs simultanés....

j'aimerai implémenter une sorte de buffering (genre un buffer de 1024Ko max) pour épargner la RAM, peut être synchroniser le remplissage de la RAM avec la lecture du fichier, enfin je ne sais pas...

Comment rendre cet envoi de fichier "par parties successives" compatible avec HTTP de plus? envoyer des trames incompletes pour chaque part de fichier?
je vais tacher de me renseigner sur les détails du protocole qui permet surement une implémentation simple de ce genre de procédé, mais en attendant, si vous avez une idée du fonctionnement, ou une maniere de faire optimisée (je parle ici surtout pour le buffering -taille idéale...-) bref, je vous en serai très reconnaissant!

merci d'avance

popstatic

PS: Fred, elle déchire la V4 ;) même en bêta!
Asus bien? asus tres bien!
Avatar de l’utilisateur
Progi1984
Messages : 2659
Inscription : mar. 14/déc./2004 13:56
Localisation : France > Rennes
Contact :

Message par Progi1984 »

Je crois bien qu'il y a dans la requete HTTP envoyée par le serveur, la possibilité de préciser que le buffer sera envoyé en plusieurs paquets. Mtnt à toi d'étudier la rfc de http 1.1
Dr. Dri
Messages : 2527
Inscription : ven. 23/janv./2004 18:10

Message par Dr. Dri »

J'avais eu le même problème, je ne me rapelle plus comment j'allais le résoudre. Je me documentais et il me semble que j'avais trouvé mais comme mon dur a sauté...

Dri :?
Avatar de l’utilisateur
Progi1984
Messages : 2659
Inscription : mar. 14/déc./2004 13:56
Localisation : France > Rennes
Contact :

Message par Progi1984 »

Ton dur m'énerve.

Envoie le moi par la poste que je le tape !
Dr. Dri
Messages : 2527
Inscription : ven. 23/janv./2004 18:10

Message par Dr. Dri »

Ah bah nan je l'ai recyclé en pinata

Dri XD
popstatic
Messages : 83
Inscription : lun. 20/sept./2004 18:21
Localisation : derriere toi fais gaffe!

Message par popstatic »

merci bien pour vos réponse rapides, bon je vais me plonger dans la RFC, faut bien passer par là de toute façon!
Asus bien? asus tres bien!
popstatic
Messages : 83
Inscription : lun. 20/sept./2004 18:21
Localisation : derriere toi fais gaffe!

Message par popstatic »

Bon alors pour information, je crois que j'ai trouvé ce qui me faut: effectivement le truc est prévu dans le protocole HTTP 1.1: en fait il faut stipuler que la propriété "Transfert-Encoding" de l'en-tête vale "chunked" (morcelé) donc:

Code : Tout sélectionner

Transfert-Encoding: chunked
on ne spécifie pas la taille du premier morceau d'apres ce que j'ai compris (je confirmerai), mais il faut inclure un "footer" (par opposition au header, ensemble de propriétés que l'on inclus non pas au debut de la trame, mais a la fin) pour signaler au browser que la suite arrive, quelle taille elle fait etc...

pour signaler la fin des chunks, il faut mettre dans le footer du dernier chunk la taille du prochain paquet à 0 octet, là le browser comprendra que c'est fini.

Simple donc, il fallait y penser....
Asus bien? asus tres bien!
Dr. Dri
Messages : 2527
Inscription : ven. 23/janv./2004 18:10

Message par Dr. Dri »

ah bah voila c'est ce que j'avais mis de côté ^^
maintenant je me rapelle qu'en l'absence de threadsafe j'étais passé à autre chose et que j'attendais la V4 pour faire du multithreading...

Dri :cry:
Répondre