Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Streaming de fichiers ascii/binaires
Bonjour. Afin de manipuler des fichiers pouvant atteindre plusieurs centaines de Mo (ascii ou binaires), je cherche à implémenter un streaming de ces fichiers en C++ pour éviter de surcharger la mémoire.
Cependant je ne sais pas trop par où commencer. En effet mon ami "gogole" ne me parle que de streaming de fichiers audio ou vidéo. Mais je n'ai pas trouvé d'algo général ni d'exemples de codes pour le streaming de fichiers de données.
Quelqu'un pourrait-il m'aiguiller??
Ouvrir socket serveur. Ouvrir socket client. Client envoie demande à serveur. Serveur ouvre fichier et envoie bout par bout au client. Client reçois données bout par bout et les stocke dans un fichier.
Forcément c'est si simple que je me doute que ta question portait sur un aspect plus spécifique, mais faudrait décrire un peu plus. Déjà rien que le terme streaming est largement perçu comme un terme pseudo-marketing et de fait n'apporte pas une grande valeur à une description technique.
Ok. Donc j'étaye. Ce "streaming" est local. En effet il s'agit de charger un fichier localement en le découpant en petits buffers que le parser de mon appli lira au fur et à mesure. Il n'y a pas de contrainte de transport via un réseau.
Si dans l'ensemble je pense avoir appréhendé la "recette" : remplissage de tampons de taille "raisonnable", empilement de ceux-ci, traitement par le parser, dépilement des tampons traités, je ne sais toujours pas trop comment partir.
Je reste donc tout ouïe.
Bonjour,
ben pourquoi ne pas commencer avec un simple ifstream pour la lecture du fichier et une simple string pour le stockage (éventuellement un vector de string)?
Voir notamment l'utilisation de la fonction membre read de ifstream (cf. cette faq)
Pourquoi ne pas utiliser les fonctionnalités de l'OS.
Tu mappes le fichier en mémoire virtuelle, cela ne coûte rien tant que les pages mémoires du fichiers ne sont pas utilisées. Ensuite, c'est l'OS qui mappe ces pages au fur et à mesure de tes demandes dans l'espace mémoire de ton process.
Sous Microsoft, j'utilise MapViewOfFile() (un point d'entrée ici : http://msdn.microsoft.com/en-us/libr...56(VS.85).aspx) et sous Linux, je pense que c'est mmap() qui fait l'équivalent.
Raymond
Vous souhaitez participer à la rubrique Réseaux ? Contactez-moi
CafuroCafuro est un outil SNMP dont le but est d'aider les administrateurs système et réseau à configurer leurs équipements SNMP réseau.
e-verbe
Ma page personnelle sur DVP.
Le problème n'est pas tant la lecture du fichier d'une manière générale. Il existe déjà un reader et un sérializer dans mon appli, ils fonctionnent très bien et s'appuient sur la gestion des flux de la STL.Envoyé par r0d
En fait j'aimerai pouvoir "streamer" le fichier comme un morceau de musique. C'est à dire que la lecture du morceau (dans mon cas le parsing de mon fichier) commence alors que celui-ci n'est pas complètement chargé en mémoire.
Ca s'éloigne un peu de ce que je voudrais faire. D'autant que j'aimerais, autant que possible, m'affranchir de fonctions "platform specific".
Mais néanmoins merci pour le lien je vais regarder ça de près.
As-tu des contraintes de synchronisation? Je demande ça car si la réponse est oui, tu va devoir passer par des threads.
Mais avec ou sans threads, le principe est le même:
1. on lit un bout du fichier que l'on met dans un buffer
2. on traite le buffer
3. retour au 1.
Non je n'ai pas de contrainte de synchro (pas encore??).
Par contre les fichiers à parser décrivent des graphs donc ça va impliquer d'autre contraintes.
Cependant pas de souci de compréhension pour le principe en général, c'est plus pour le codage à proprement parler que ça coince.
Je ne sais pas trop comment partir.
Il va sûrement falloir que je définisse de nouvelles structures de données (StreamBuffer avec la possibilté d'interroger son état : ecriture / lecture / lu, une pile de StreamBuffer ...?)
De plus le fait de faire une boucle qui remplit au fur et à mesure des tampons, les empile en attendant qu'ils soient traités, n'est ce pas bloquant? Car pendant ce temps là on ne peut rien faire d'autre. En relisant ça, ça sent les threads non?
Salut,
Pour t'aider il faut preciser l'utilisation du fichier. Tu parles d'un graph, est ce que tu fais un visualiseur de données sous forme de graph avec quelle option ( zoom, deplacement ?). Et comment est structuré ton programme, peut tu deplacer dans ton fichier facilement sans l'avoir précedement parcourt pour l'indexer ?
Effectivement, tu ne fournis pas assez de précisions pour que nous puissions t'aider. Surtout si tu dis que ton problème est au niveau du code, et non de l'algorithme.
Ben oui, la lecture d'un fichier (de même que les traitements) sont bloquants. Comme toute fonction c++. Là je crois que ton problème est plus général et très simple: tu veux faire deux choses en même temps, donc oui, il te faut deux threads.
Il ne s'agit pas de visualiser des données sous forme de graphe. Les données sont déjà organisées sous la forme d'un graphe hiérarchisé.
En fait mon appli permet de visualiser des graphes de scènes avec OpenGL. Donc sans trop rentrer dans les détails de l'implémentation, je dispose d'une API décrivant différents noeuds avec différentes propriétés, qui "assemblés" constituent un graphe de scène. Le chargement est classique c'est à dire que le fichier est entièrement chargé en mémoire, puis parsé. Maintenant il faudrait que je le "streame" pour éviter de saturer la mémoire lorsque les fichiers sont très volumineux.
Pour ce qui est de me déplacer dans mon fichier, je me sers de ce qui existe dans ifstream.
Je le referai plus(cf post précédent)
Hmm. Je sens que le design de ce machin va être chiant...Ben oui, la lecture d'un fichier (de même que les traitements) sont bloquants. Comme toute fonction c++. Là je crois que ton problème est plus général et très simple: tu veux faire deux choses en même temps, donc oui, il te faut deux threads.
Question: Est-ce que tu dois/peux modifier cette API ou juste te débrouiller pour la faire fonctionner différement mais sans la modifier?
C'est le métier qui rentreJe le referai plus
En plus tu verras que souvent, en faisant un effort pour expliquer précisément un problème, on trouve soi-même la réponse. En effet, pour expliquer clairement et le plus succintement possible un problème, on est obligé de synthétiser, de trier ce qui est important et ce qui ne l'est pas, de classer les différentes donnés du problème, etc... et ce travail est souvent suffisant pour trouver une solution.
Ben à première vue, ça ne me parait pas si compliqué.Hmm. Je sens que le design de ce machin va être chiant...
Creer un thread pour faire tourner ton "module" (lecture fichier + traitement données) est très simple: d'abord tu le fais fonctionner en "simple thread", ensuite l'encapsulation dans un thread est très simple, surtout si les données de ce "module" sont indépendantes du reste de l'application.
Je peux modifier "un peu" l'API. Le but étant la rétro compatibilité entre la nouvelle version et les précedentes. Cependant tant que ça ne casse pas le fonctionnement même de celle-ci, c'est bon, je peux ajouter pleins de trucs.
Je voyais pas ça de cette façon.
->un thread dépiler les buffer "traités", lire le fichier, remplir les buffers à parser et empiler ceux-ci.
->un thread (qui démarre dès qu'il y a au moins un buffer) pour parser le contenu du buffer et le taguer comme "traité" quand il est fini d'être parsé.
Ca semble cohérent ou bien je me fourvoie?
Ca me parait compliqué, mais je connais moins bien le contexte que toi.
Si j'ai bien compris, la solution que tu proposes contiendra 2 threads en plus du processus principal. Et ces 2 threads devront être synchronisés, ce qui implique des sections critiques, des mutex et tout le toutim.
Il me semble (mais encore une fois, je ne connais pas le contexte) que le mieux, car le plus simple, est de faire tout dans le même thread: lecture, gestion des buffers et traitement.
Prenons un exemple simple: tu as 2 buffers. Un pour la lecture, un pour le traitement (les détails d'implémentations - copie ou swap, taille des buffers, marqueurs, etc - dépendrons des contraintes). Dans ta boucle, tu remplis ton buffer de lecture, tu le copie dans le buffer de traitement (plus grand que le buffer de lecture), et tu demandes à ton API de faire un traitement sur ce buffer. Si elle n'a pas assez de données, la fonction de traitement renvoie "false", et on repart pour une boucle de lecture/remplissage.
Tu met cette boucle dans un thread, ce qui permet au reste de ton appli de tourner sans se préoccuper de tout ça.
Au final on a qu'un thread, et aucun problème de synchronisation.
Ah ouais
Je me complique effectivement un peu la vie. Bah c'est pas grave c'est aussi pour ça que je suis là.
Par contre pas possible pour moi de repartir sur une boucle de lecture/remplissage si j'ai pas assez de données. En effet, dans un graphe de scène, il se peut qu'un noeud contienne tous les autres noeuds, et qu'il commence au début du fichier et se termine à la fin de celui-ci.
Je vais réflechir un peu plus à la conception et faire par de mes avancés ET mes éventuelles questions.
Ben moi j'ai toujours pas compris la problématique
Est-ce un problème de temps : la lecture est trop longue du coup elle bloque l'application.
Ou est-ce un problème de mémoire : les données prennent trop de place en mémoire toutes ensembles, tu cherche à travailler sur une petite partie du fichier à la fois.
Si cette situation arrive souvent, je ne vois pas comment tu peux lire autrement ton fichier qu'en une seul fois.En effet, dans un graphe de scène, il se peut qu'un noeud contienne tous les autres noeuds, et qu'il commence au début du fichier et se termine à la fin de celui-ci.
Si ton format de fichier le permet, tu pourrais essayer d'effectuer une lecture aléatoire de ton fichier. Dans le cas où tu as la position de début et de fin de tes noeuds... mais s'il s'agit d'un format du genre xml, ça va pas être facile.
D'après ce que j'ai compris le but est de commencer à afficher une scène avec des délais des lancement aussi courts que possible sans se soucier du fait que, forcément, la scène sera incomplète pendant un temps avant d'être stabilisée, un peu comme avec les JPEG entrelacés qui gagnent en précision au fur et à mesure qu'on les télécharge.Ben moi j'ai toujours pas compris la problématique
Est-ce un problème de temps : la lecture est trop longue du coup elle bloque l'application.
Ou est-ce un problème de mémoire : les données prennent trop de place en mémoire toutes ensembles, tu cherche à travailler sur une petite partie du fichier à la fois.
Ca me fait penser au mode de fonctionnement de Second Life ça, je me trompe?
Sinon, si le but est simplement d'éviter de charger un fichier entièrement en mémoire, les accès aléatoires dans les fichiers ça existe, de même qu'il existe des formats de description d'objets 3D qui n'en nécessitent pas.
Répondre avec citation
Partager