[Perl] communication Inter-Processus

Version imprimable

10/08/2006, 15h52
MarneusCalgarXP

[Perl] communication Inter-Processus

J'aimerais bien écrire une application perl, disons un démon, qui possederait une hashmap, avec par exemple 3 champs, toto, titi et tata.

Comment faire pour rendre cette map disponible pour d'autres programmes perl, et qu'un programme perl réussisse à obtenir la donnée correspondante à toto, titi ou tata en passant par le nom de la clé, par exemple &getData('titi') appelée depuis le programme distant permettrait d'obtenir le contenu de $map('titi') du démon ?

Je ne suis peut-être pas très clair. Disons que j'aimerais réaliser une communication inter-processus en perl. Est-ce possible ? et si oui, comment ?
10/08/2006, 15h58
Woufeil

Bonjour,

Et bien pour fair ce genre de choses, je te conseille d'utiliser un pipe (solution qui fonctionne sous les systèmes Unix/Linux, MacOS et Windows qui plus est) ou même simplement un appel système...
A partir de ton démon, tu appelles le programme perl que tu veux en lui passant ce que tu veux comme paramètre. Dans ce programme, le paramètre sera accessible dans le tableau @ARGV.
10/08/2006, 16h13
MarneusCalgarXP

Malheureusement, le démon occupe 50% de la RAM, et de nombreux process doivent être lancés. chaque process ne doit récupérer qu'une variable ou 2 de la hash stockée par le démon. Si je suis ta méthode, au bout de 2 process, j'ai déjà explosé la RAM disponible !
10/08/2006, 16h26
Woufeil

Je ne comprend pas bien ce que tu veux dire... A partir de ton démon, tu lances chaque process en lui passant le paramètre nécéssaire... Exemple :
system("C:\tonscript.pl $hash{'cle'}); va appeller le script tonscript.pl en lui passant $hash{'cle'} comme paramètre. Dans tonscript.pl, ce paramètre sera accessible par $ARGV[O]...
10/08/2006, 16h30
MarneusCalgarXP

Ah ok, je vois ce que tu veux dire, cependant, la valeur de ce paramètre peut changer en cours de route...

D'autant que certains scripts peuvent avoir besoin d'une centaine de paramètres, donc si on utilise cette méthode, ce n'est pas véritablement gérable !
10/08/2006, 17h38
Jedai

Le plus simple me semble-t-il serait d'utiliser un serveur, non ?

(Sinon tu peux faire des tas de trucs non portables (partager la mémoire, passer des messages, etc), mais je ne vois pas trop l'intérêt par rapport à un serveur sauf si tu cherches vraiment les performances)

--
Jedaï
10/08/2006, 23h42
MarneusCalgarXP

Ok pour un serveur, mais comment faire pour gérer plusieurs connexions simultanées sans avoir à forker ? après plusieurs tests, on soupçonne fortement que le fork provoque une duplication de la mémoire, hors le démon occupant déjà 50% de la RAM, si je fork 2 ou 3 fois, ca risque d'occuper plus de mémoire que ce dont la machine dispose !

Est-ce que je me trompe, et donc que le fork ne duplique pas l'intégralité de la mémoire occupée ? (ce serait cool ;) )

Et y-a-t-il une manière simple d'écrire un serveur tcp en perl ? (un module CPAN par exemple ;) )
10/08/2006, 23h57
Jedai

D'après ce que j'ai compris, le transit d'information sera relativement faible sur ces connexions de toute façon, chaque requête sera traité pratiquement instantanément, donc tu peux tout à fait faire un serveur à select().

Un démon qui occupe 50% de la RAM... A quoi sert-il donc ? (si ce n'est pas indiscret)

--
Jedaï
11/08/2006, 00h50
Woufeil

Citation:

Envoyé par MarneusCalgarXP

Est-ce que je me trompe, et donc que le fork ne duplique pas l'intégralité de la mémoire occupée ? (ce serait cool ;) )

Juste pour info, tu ne te trompes absolument pas. En fait, lors d'un fork, Perl clone l'interpréteur en cours pour lancer le nouveau processus. Cela permet d'assurer la portabilité sous toutes les plateformes.
Mais de toute façon, il me semble que la fonction C fork clone aussi le processus courant.
11/08/2006, 18h25
MarneusCalgarXP

Citation:

Envoyé par Jedai

D'après ce que j'ai compris, le transit d'information sera relativement faible sur ces connexions de toute façon, chaque requête sera traité pratiquement instantanément,

Effectivement, lorsqu'une application se connectera au démon, elle récupérera certaines informations et se déconnectera aussitôt. Le problème principal vient du fait qu'il peut il y avoir plusieurs dizaines de process qui tournent simultanément, donc il y a toujours des risques de collision... Je suppose qu'il est possible de mettre en place un système de timeout pour attendre une réponse du serveur.

Citation:

donc tu peux tout à fait faire un serveur à select().

C'est à dire ? aurais-tu un exemple ?

Citation:

Un démon qui occupe 50% de la RAM... A quoi sert-il donc ? (si ce n'est pas indiscret)

Disons que nous gérons une quantité d'informations assez considérable (plusieurs To par jour), et qu'un certain nombre d'indicateurs sont calculés en cascade. Pour permettre de faciliter les calculs terminaux, le démon stocke les indicateurs intermédiaires, et les rend disponible...
11/08/2006, 18h38
Jedai

Citation:

Envoyé par MarneusCalgarXP

Effectivement, lorsqu'une application se connectera au démon, elle récupérera certaines informations et se déconnectera aussitôt. Le problème principal vient du fait qu'il peut il y avoir plusieurs dizaines de process qui tournent simultanément, donc il y a toujours des risques de collision... Je suppose qu'il est possible de mettre en place un système de timeout pour attendre une réponse du serveur.

Tu n'as jamais fait de serveur je suppose ? Il n'y a pas de risque de collision avec un serveur TCP/IP, chacune des connexions est indépendante. Regarde donc du côté de module comme Net::Server, particulièrement Net::Server::Multiplex.
Aussi, si les informations que vous avez à gérer sont au moins en partie de nature numérique, jette un coup d'oeil à PDL.

--
Jedaï
12/08/2006, 10h37
MarneusCalgarXP

Merci pour les liens, je vais y jeter un coup d'oeil de pas !!

Sinon, j'ai déjà réalisé un ou deux serveurs dans d'autres langages, mais ce que j'appellais "collision" dans mon message, c'est une séquence du type

* tentative de connexion au serveur
* socket serveur déjà occupé, attente de libération d'une socket
* timeout dépassé
* connexion échouée

qui n'arrive bien entendu que dans le cas d'un serveur monosocket, ou d'un serveur multisocket dont le nombre de socket maximal est atteint !
12/08/2006, 14h44
Jedai

Citation:

Envoyé par MarneusCalgarXP

Merci pour les liens, je vais y jeter un coup d'oeil de pas !!

Sinon, j'ai déjà réalisé un ou deux serveurs dans d'autres langages, mais ce que j'appellais "collision" dans mon message, c'est une séquence du type

* tentative de connexion au serveur
* socket serveur déjà occupé, attente de libération d'une socket
* timeout dépassé
* connexion échouée

qui n'arrive bien entendu que dans le cas d'un serveur monosocket, ou d'un serveur multisocket dont le nombre de socket maximal est atteint !

D'accord, mais vu le type de requête que tu veux faire, ce n'est pas avec quelques dizaines de processus simultanés que tu vas engorger le serveur, non ?

--
Jedaï
12/08/2006, 22h53
MarneusCalgarXP

D'accord, mais donc on en revient à ma problématique initiale.
Est-ce possible, en perl, de réaliser un serveur, avec une seule instance des données (~50% de la RAM), mais qui propose plusieurs sockets ?
13/08/2006, 00h11
Jedai

Comme je te l'ai déjà dit Net::Server::Multiplex est l'une des solutions. Il y a plusieurs sockets dans ce cas, simplement il n'y a pas plusieurs processus pour les servir, c'est pourquoi ce n'est adapté que si tu peux traiter chaque requête assez rapidement (tu peux avoir autant de connexions actives en même temps que tu veux par contre), mais dans ce cas c'est même plus efficace globalement que de faire du fork (évidemment je parle dans le contexte de machines normales, pas massivement parallèles).

--
Jedaï
14/08/2006, 22h43
MarneusCalgarXP

Ok, je ne l'avais pas compris comme ça ! Je te remercie beaucoup, je vais tenter de créer un serveur de test, et si j'ai des problèmes, je reviendrais t'embetter ;)