Démon, socket, sandbox, mémoire partagée ... ?
Posté : 31 juil. 2009, 22:56
Hey 
,
Alors voilà, j'ai un gros dilème à résoudre. Accrochez-vous bien, ça risque d'être un peu compliqué mais je vais faire mon maximum
.
Le but du jeu est de faire communiquer une application PHP (A) avec une autre application PHP (B). Ce n'est pas seulement un bête Hello World que l'on va devoir envoyer, mais des objets, des ressources etc. Les deux applications sont exécutées en même temps sur la même machine. Pour ça, on a plusieurs solutions.
Mémoire partagée
PHP propose l'extension Shared Memory qui permet de créer des blocs de mémoire partagée. On peut imaginer A écrire dans un bloc et que B le lise.
Avantage : très rapide.
Inconvénient : l'extension existe partout mais n'est pas forcément compilée (même si sous les *AMP habituelles, on l'a, tout comme les compilations par défaut), on peut avoir des gros problèmes de sécurité (seulement entre PHP normalement), pas simple à gérer.
Démon ou socket
Le but est de créer un client et un serveur qui s'écoutent et s'écrivent mutuellement. A peut être le client et B peut contenir le serveur. Autre configuration possible, on a A qui est le client, notre serveur et B un autre client ; dans ce cas, le serveur est une sorte de pivot. Bref, ça ne change pas grand chose.
Dans le cas d'un démon, c'est le même problème. Le fonctionnement reste celui d'un client-serveur.
Inconvénient :
On va devoir sérialiser les données pour les envoyer dans le flux client-serveur. On note que des données comme des objets ou des ressources peuvent mal se sérialiser. On risque donc de perdre des informations, notamment dès qu'une référence (autre qu'un objet) se présente, l'information est perdue. On va essayer de considérer qu'il ne faut pas perdre les références pour l'évolution du projet.
Avantage :
Des protocoles comme UDP ou TCP ne sont assez utiles pour répondre à nos besoins. On peut donc créer notre propre protocole en passant par des fichiers que l'on gère nous même, ou en passant par la mémoire de PHP directement (voir php://memory ou php://temp). On règle tout comme on veut, pas de problème. Mais ça nécessite encore une fois de sérialiser nos données. Et autre cas, si on sérialise une ressource, il y a très peu de chance qu'elle fonctionne encore une fois désérialisée dans un nouvel environnement d'exécution (on pense notamment une connexion vers les bases de données).
Oui mais :
Il faut voir la sérialisation comme un mode lecture-seule dans le pire des cas. Si on considère qu'on ne veut que lire les informations, alors ce n'est pas grave de sérialiser les données et un cilent-serveur fait l'affaire. Mais ce serait contraignant pour ce que je veux faire. Je préfère donc pour l'instant éviter et me rabattre sur cette solution si on ne trouve rien de mieux.
Sandbox
Je n'ai pas trouvé mieux comme moyen de résoudre mon problème : au lieu d'exécuter deux applications et de les faire se causer, on peut les exécuter l'une dans l'autre. L'idée est d'avoir B qui exécute A par exemple. B immite l'environnement d'exécution de A. On fait de la virtualisation en quelque sorte. Comme ça, plus besoin de les faire communiquer, elles partagent la mémoire et on peut retrouver toutes les données sans perdre de l'information.
Avantage :
Supprime tous les problèmes liés à la sérialisation.
Inconvénient :
On doit exécuter notre application depuis une sorte de machine virtuelle. C'est peut-être un brin contraignant pour les développeurs à utiliser, même si ça resterait très simple : une simple ligne de commande dans un terminal.
Toutefois, il existe des risques que certaines actions très particulières ne puissent être réalisées comme il se doit (d'où la difficulté de la virtualisation).
Donc voilà mon dilème. Je vous ai exposé mes quelques idées. Est-ce vous pouvez les commenter ou m'en soumettre de nouvelles ?
Merci.
,Alors voilà, j'ai un gros dilème à résoudre. Accrochez-vous bien, ça risque d'être un peu compliqué mais je vais faire mon maximum
.Le but du jeu est de faire communiquer une application PHP (A) avec une autre application PHP (B). Ce n'est pas seulement un bête Hello World que l'on va devoir envoyer, mais des objets, des ressources etc. Les deux applications sont exécutées en même temps sur la même machine. Pour ça, on a plusieurs solutions.
Mémoire partagée
PHP propose l'extension Shared Memory qui permet de créer des blocs de mémoire partagée. On peut imaginer A écrire dans un bloc et que B le lise.
Avantage : très rapide.
Inconvénient : l'extension existe partout mais n'est pas forcément compilée (même si sous les *AMP habituelles, on l'a, tout comme les compilations par défaut), on peut avoir des gros problèmes de sécurité (seulement entre PHP normalement), pas simple à gérer.
Démon ou socket
Le but est de créer un client et un serveur qui s'écoutent et s'écrivent mutuellement. A peut être le client et B peut contenir le serveur. Autre configuration possible, on a A qui est le client, notre serveur et B un autre client ; dans ce cas, le serveur est une sorte de pivot. Bref, ça ne change pas grand chose.
Dans le cas d'un démon, c'est le même problème. Le fonctionnement reste celui d'un client-serveur.
Inconvénient :
On va devoir sérialiser les données pour les envoyer dans le flux client-serveur. On note que des données comme des objets ou des ressources peuvent mal se sérialiser. On risque donc de perdre des informations, notamment dès qu'une référence (autre qu'un objet) se présente, l'information est perdue. On va essayer de considérer qu'il ne faut pas perdre les références pour l'évolution du projet.
Avantage :
Des protocoles comme UDP ou TCP ne sont assez utiles pour répondre à nos besoins. On peut donc créer notre propre protocole en passant par des fichiers que l'on gère nous même, ou en passant par la mémoire de PHP directement (voir php://memory ou php://temp). On règle tout comme on veut, pas de problème. Mais ça nécessite encore une fois de sérialiser nos données. Et autre cas, si on sérialise une ressource, il y a très peu de chance qu'elle fonctionne encore une fois désérialisée dans un nouvel environnement d'exécution (on pense notamment une connexion vers les bases de données).
Oui mais :
Il faut voir la sérialisation comme un mode lecture-seule dans le pire des cas. Si on considère qu'on ne veut que lire les informations, alors ce n'est pas grave de sérialiser les données et un cilent-serveur fait l'affaire. Mais ce serait contraignant pour ce que je veux faire. Je préfère donc pour l'instant éviter et me rabattre sur cette solution si on ne trouve rien de mieux.
Sandbox
Je n'ai pas trouvé mieux comme moyen de résoudre mon problème : au lieu d'exécuter deux applications et de les faire se causer, on peut les exécuter l'une dans l'autre. L'idée est d'avoir B qui exécute A par exemple. B immite l'environnement d'exécution de A. On fait de la virtualisation en quelque sorte. Comme ça, plus besoin de les faire communiquer, elles partagent la mémoire et on peut retrouver toutes les données sans perdre de l'information.
Avantage :
Supprime tous les problèmes liés à la sérialisation.
Inconvénient :
On doit exécuter notre application depuis une sorte de machine virtuelle. C'est peut-être un brin contraignant pour les développeurs à utiliser, même si ça resterait très simple : une simple ligne de commande dans un terminal.
Toutefois, il existe des risques que certaines actions très particulières ne puissent être réalisées comme il se doit (d'où la difficulté de la virtualisation).
Donc voilà mon dilème. Je vous ai exposé mes quelques idées. Est-ce vous pouvez les commenter ou m'en soumettre de nouvelles ?
Merci
.
?