IPC Unix type client/serveur

Bonjour à tous,

J'ai actuellement un programme qui lit un fichier qui me sert de base de données afin d'effectuer de rechercher des informations. Le problème est que le programme relit le fichier à chaque execution.
Je cherche un moyen de ne pas relire ce fichier à chaque fois que je cherche une information dans ces données, un système du type client/server. Le serveur a donc les données en mémoire et attend les instructions d'un programme client. Le résultat de la commande peut être assez volumineux.

Je sais qu'il existe les sockets Unix mais l'échange de données entre le client et le serveur est assez complexe. J'ai une implémentation avec des sockets SOCK_STREAM mais je n'arrive pas à échanger l'intégralité d'1 Mo.

Merci d'avance pour vos suggestions !

C'est à dire? Tu n'arrives pas à récupéré les données? Elles ne sont pas transmise par le reseau? Explique un peu plus ton problème avec quelque bout de code qui concerne ce soucis, on sera plus à-même de t'aider :).

n'oublie pas que tu devrais pouvoir transmettre ton méga par morceaux

En fait je cherche principalement d'autres idées que les sockets Unix domain.

Avant d'améliorer mon implémentation avec les sockets j'aimerais d'abord savoir si d'autres moyens sont plus pertinents, simples et/ou efficaces.

Si tu peux utiliser le C++, il y a boost.asio
Je ne sais plus quel est l'éventail des possibilités de curl, qui fait entre autre des requetes http, mais qui, je crois, est plus large que ca.

Malheureusement je ne peux utiliser que du C.

Je n'ai pas forcement besoin d'utiliser des bibliothèques réseaux vu que je fais de la communication entre processus sur une même machine.

Est ce qu'il y a un manière simple en C de faire tourner un programme qui attend les instructions d'un programme client et lui renvoie les résultats de l'execution ?

Citation:

---

Envoyé par nezix

Est ce qu'il y a un manière simple en C de faire tourner un programme qui attend les instructions d'un programme client et lui renvoie les résultats de l'execution ?

---

Tu as la main sur les deux programmes ? Si oui, tu peux passer par des segments de memoire partagee, par des sockets, par un fichier, par une base de donnée, ...

Dans ton cas, il nous manque quelques infos pour pouvoir vraiment bien te répondre, mais je pense que les sockets ou la memoire partagée sont tous deux une bonne solution.

Citation:

---

J'ai actuellement un programme qui lit un fichier qui me sert de base de données afin d'effectuer de rechercher des informations. Le problème est que le programme relit le fichier à chaque execution.

Je cherche un moyen de ne pas relire ce fichier à chaque fois que je cherche une information dans ces données, un système du type client/server. Le serveur a donc les données en mémoire et attend les instructions d'un programme client. Le résultat de la commande peut être assez volumineux.

---

La vraie question est : est-ce que ton fichier se trouve actuellement sur la même machine que ton programme (en dépit de l'architecture client-serveur que tu veux mettre en place) ?

Si c'est le cas, tu n'as rien à faire puisque le système d'exploitation lui-même va mettre en mémoire cache les informations qu'il lira dans ton fichier. Relire ces informations sera alors aussi efficace que les garder toi-même en mémoire, et même plus puisque le système aura latitude pour les organiser à bon escient. Si tu lui demandes de tout garder en mémoire et qu'il en manque, il pourrait se retrouver obligé de les mettre dans le swap, ce qui serait un comble.

La seule chose qui pourrait plomber tes performances est la façon dont est structuré ton fichier. S'il s'agit d'un fichier séquentiel, comme un fichier texte ligne à ligne, alors ton programme est obligé de le relire à chaque fois depuis le début pour retrouver la bonne information. Non seulement c'est long en soi, mais ça invalide forcément le cache si celui-ci est trop petit. En te penchant sur la chose et en choisissant une solution adaptée, tu vas faire un bond de géant à tes perfs.

J'ai la main sur les deux programmes, je dois les développer.

Explications : Je lis un fichier assez volumineux qui contient une masse d'informations triées. Je dois actuellement la trier à nouveau ces informations et les ré-écrire dans ce fichier si je veux insérer une donnée (je fais ça avec un timsort qui va bien). Je suis aussi obligé de lire ce fichier à chaque fois que je cherche une info dans ces données puis de faire une recherche binaire et enfin traiter les données. Je pourrais utiliser une table de hachage mais là n'est pas tellement le problème.

J'aimerais donc me passer de l'étape écriture et lecture du fichier à chaque execution en ayant un programme qui garde ses informations en mémoire et attend les requêtes du client, que ce soit une insertion, une recherche et traitement de données, une suppression...

Citation:

---

Envoyé par Obsidian

La vraie question est : est-ce que ton fichier se trouve actuellement sur la même machine que ton programme (en dépit de l'architecture client-serveur que tu veux mettre en place) ?

---

Oui c'est bien sur la même machine.

Citation:

---

Envoyé par Obsidian

Si c'est le cas, tu n'as rien à faire puisque le système d'exploitation lui-même va mettre en mémoire cache les informations qu'il lira dans ton fichier.

---

D'autres processus vont tourner sur le même principe donc je ne peux pas me fier à la mise en cache des informations par le système.
A priori la mémoire n'est pas un problème donc pas de problème de swap mais je dois en tenir compte si mes données venaient à grandir.

Citation:

---

Envoyé par Obsidian

La seule chose qui pourrait plomber tes performances est la façon dont est structuré ton fichier.

---

J'ai fait un index de mes données pour que la recherche pointe directement sur une région qui contient les informations.

Si ton fichier contient des données volumineuse, l'idéal serait de passé par une base de donnée, c'est rapide et simple d'implémentation. Ensuite si tu veux garder un système de fichier pour les stockage, tu as mmap qui permet de stocker des données dans un fichier et non pas directement dans la mémoire.

Si les deux processus sont sur le meme poste, la mémoire partager peut-etre utilisé, mais il faut préféré des petites quantité de donnée pour que celle-ci soit efficace, comme je l'ai dis je pense qu'une base de donnée serait vraiment efficace dans ton cas :).

Le compromis entre les deux est sqlite, qui fonctionne avec une base de donnée constituée d'un unique fichier.

C'est vrai que sqlite est intéressant mais je ne suis pas super familier avec les bases de données et surtout SQL et j'essaye d'avoir une implémentation simple.

Si j'implémente une solution avec les sockets Unix ou de la mémoire partagée, c'est comme si j'avais un serveur local qui répond à des requêtes standardisées mais potentiellement plus rapide que sqlite (on peut rêver).

Pas plus rapide, sqlite n'utilise pas de ressource réseau.
Et une fois la table créée, tu n'auras surtout besoin que de SELECT et INSERT, qui sont très optimisés par sqlite.

Et puis, c'est l'occasion de découvrir SQL :mrgreen:

Je confirme le bienfondé d'utiliser sqlite : ça devrait t'enlever pleins de soucis de gestion à la main.

Merci de votre aide, je vais voir du côté de sqlite et comparer avec ce que j'ai fait.