Mémoire partagée entre deux processus

[Sutat]

Bonjour,

J'aimerais faire un serveur multi-processus.
La contrainte que j'ai c'est que les deux processus doivent communiquer.

Je connais la mémoire mappée (déjà utilisée pour un autre projet), mais je crois qu'il est nécessaire de définir la taille maximum de la mémoire mappée (pas dynamique donc).
Or la mémoire que je dois partager entre les deux processus n'est pas fixe.

J'ai lu sur ce dit forum qu'on pouvait utiliser pipe() sur un FD, mais je ne sais pas si c'est indiqué pour des traitements volumineux (je dois avoir des temps de réponses courts).

Est-ce que vous avez des retours d'expérience à partager sur ce sujet ?
De la documentation à me donner ?
Est-ce que les pipes sont performants ? (Ca passe par la mémoire directement ou par le disque dur ?).

--

Résumé :

J'aimerais communiquer entre deux processus par des variables en RAM, avec autant de rapidité que dans un seul processus et sans avoir à définir la taille de cette mémoire partagée.

--

Merci beaucoup

[Sutat]

Bon j'ai essayé les pipe.
Ca fonctionne bien, par contre niveau design de mon serveur je me dis que finalement ça ne va pas être tip top d'utiliser des pipes, je m'explique :
1. Je voulais faire un serveur dont le métier était détaché de la couche de persistance. L'idée c'était que si mon métier plante, je peux toujours sauvegarder mes données.

2. En partant de ça, je voulais en profiter pour faire une sorte de cache niveau deux à la hibernate sur le gestionnaire de données. Comme ça à chaque appel de mon métier si j'avais déjà les données en RAM je lui donné un pointeur sur cette donnée et je n'avais pas à ouvrir tout le temps des transactions, faire des flush etc.

Le problème avec les pipes c'est que je ne vais pas pouvoir faire tout ça, je vais dupliquer les données si je passe par un pipe.
Du coup je suis en train de me dire que faire deux processus distinct pour cette gestion de données ne va pas être possible non plus (a moins que je map une quantite folle de mémoire à l'initialisation, parfois pour rien).

Bref, je pense que le design du serveur n'est pas bonne et je vais être obligé de ne faire qu'un processus entre le métier et le gestionnaire de données. Au risque que le metier crash (et en conséquence, que je perde des données).

[gangsoleil]

Bonjour,

C'est un probleme de conception, pas de langage.

Maintenant que tu as explique le probleme, on peut commencer a reflechir a des solutions qui seraient bonnes, ou tout du moins meilleures que celle que tu as imagine pour le moment.

[souviron34]

Envoyé par Sutat

Bref, je pense que le design du serveur n'est pas bonne et je vais être obligé de ne faire qu'un processus entre le métier et le gestionnaire de données. Au risque que le metier crash (et en conséquence, que je perde des données).

Tu pourrais faire 2 serveurs .. Pourquoi un seul ??

Un "métier" qui appelle un "données"

le "données" peut avoir soit une "base" mappée ou non en mémoire qui concerne ce qu'il est en train de traiter, et qui est soit sauvegardée lors d'un crash soit récupérée lors de la reprise suivante...

[Sutat]

Salut souviron34,

En fait c'est un peu ce que je voulais faire au début.
Mais le problème c'est qu'avec ces deux serveurs, je vais dupliquer la mémoire de ma base de données.
Il y a aurait :
- les données de ma base de données (avec un cache j'imagine)
- les données mappée dans des instances DTO sur mon serveur de données
- les données traitées (aussi mappée) dans des instances DTO sur mon serveur métier (jeu)

Le must, ce serait que mon serveur de données puisse donner un pointeur vers un DTO déjà mappé (ou non) et que l'autre serveur (donc un autre processus) ait les autorisations pour y accéder.

[wiztricks]

Salut,

Envoyé par Sutat

Résumé :
J'aimerais communiquer entre deux processus par des variables en RAM, avec autant de rapidité que dans un seul processus et sans avoir à définir la taille de cette mémoire partagée.

Pourquoi ne pas utiliser des threads, i.e. 2 process qui partagent le même espace virtuel?
- W

[Sutat]

Parce que l'idée de base c'est que si mon programme plante (pour une quelconque raison), je voudrais que l'autre continue à fonctionner pour sauvegarder mes données.

Avec deux processus c'est gérable, dans des threads je ne sais pas.

edit : Mais si je ne trouve pas comment faire avec deux processus (ou client/serveur) sans dupliquer la RAM je vais effectivement passer par des threads.

[souviron34]

Envoyé par Sutat

Salut souviron34,

En fait c'est un peu ce que je voulais faire au début.
Mais le problème c'est qu'avec ces deux serveurs, je vais dupliquer la mémoire de ma base de données.
Il y a aurait :
- les données de ma base de données (avec un cache j'imagine)
- les données mappée dans des instances DTO sur mon serveur de données
- les données traitées (aussi mappée) dans des instances DTO sur mon serveur métier (jeu)

Le must, ce serait que mon serveur de données puisse donner un pointeur vers un DTO déjà mappé (ou non) et que l'autre serveur (donc un autre processus) ait les autorisations pour y accéder.

l'avantage d'avoir 2 serveurs c'est qu'ils ne sont pas forcément sur la même machine....

Secondo, je ne sais pas ce que c'est que DTO

quand je disais "mappé", cela pouvait être en mémoire ou en cache disque.

Enfin, j'avoue avoir un peu de mal à voir le distinguo que tu fais entre données traitées et non traitées. Tes données "traitées" vont-elles être stockées quelque part ou c'est juste "au vol" ?

Enfin, la "duplication", qu'elle soit physique (disque) ou "mémoire") (mémoire partagée) n'est absolument pas obligatoire si justement ce "mappage" est bien conçu (sauf si c'est sur des machines différentes, et même mà on peut s'arranger)

[Sutat]

DTO : http://en.wikipedia.org/wiki/Data_Transfer_Object
Une instance d'un DTO A c'est en fait une ligne (tuple) de la table A.

Oui avoir deux serveur c'est bien pour la répartition de la charge.
Mais tu es d'accord que pour un programme a faible latence (ici pour un jeu), je ne vais pas appeler mon serveur à chaque fois que j'ai besoin d'une donnée ?

Serveurs
Alors si je continue sur ton idée de serveur, et pour avoir une faible latence. Je vais avoir :
sur le serveur D (données) :
- 1 cache de données avec des DTO (la représentation objet de mes tables) [1]
- Des sockets d'envoie de ces données.

sur le serveur J (Jeu) :
- 1 cache de données avec des DTO. [2]
- Le métier.

[1] : Il me sert a accéder moins souvent à la base
[2] : Il me sert à ne pas tout le temps accéder à mon serveur de cache

On voit bien que je suis obligé de dupliquer le comportement de cache. C'est contre productif.

Théorie
Le meilleurs schéma en théorie serait pour moi :
sur le serveur D (données) :
- 1 cache de données avec des DTO (la représentation objet de mes tables)
- Interface imaginaire (c'est là que je n'ai aucune idée de ce que je peux faire)

sur le serveur J (Jeu) :
- Des pointeurs sur les données du serveur D.
- Le métier.

La je ne duplique pas la mémoire, j'accède à mes données du serveur D directement quand j'en ai besoin par les pointeurs.
Si mon serveur J plante, mon serveur D peut le détecter et sauvegarder son cache en base de données (flush).

Conclusion :
Est-ce que la section "théorie" est réalisable avec :

• Des serveur ?
  • Duplication de données
  • Duplication du système de cache
  • Répartition de la charge
  • Système de secours des données
• Des processus ?
  • Duplication de données (pipe)
  • Pas de répartition de la charge possible
  • Système de cache centralisé
  • Système de secours des données
• Des threads ?
  • Pas de système de secours des données
  • Pas de répartition de la charge possible
  • Données centralisées
  • Système de cache centralisé

Je crois que la réponse est non. A moins que vous avez quelque chose sous la main que je ne connais pas.

Je vais surement aller sur les threads, et faire plus souvent des flush BDD que si j'étais sur un serveur de cache. C'est la solution qui me donnera le moins de latence je pense.