Démon, socket, sandbox, mémoire partagée ... ?

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : Démon, socket, sandbox, mémoire partagée ... ?

Re: Démon, socket, sandbox, mémoire partagée ... ?

par ouckileou » 07 août 2009, 11:20

Dans un message tu mets ce que tu veux mais c'est sérialisé derrière, pareil :)

Re: Démon, socket, sandbox, mémoire partagée ... ?

par Hywan » 07 août 2009, 10:41

C'est l'idée oui, un client-serveur tout bêtement, mais au lieu d'envoyer des bêtes messages, on enverrait des données PHP, sous sa forme PHP et pas sous une forme sérialisée quelconque. Java Message Service a priori envoie des messages, et pas des données Java, me trompe-je ?

Re: Démon, socket, sandbox, mémoire partagée ... ?

par ouckileou » 06 août 2009, 18:00

C'est un équivalent de JMS que tu veux en fait ?

Re: Démon, socket, sandbox, mémoire partagée ... ?

par Hywan » 06 août 2009, 15:30

Un Webservice c'est un client-serveur. Je ne veux pas remonter vers ces couches haut-niveaux, je veux rester au niveau de PHP, rester dans PHP.

Re: Démon, socket, sandbox, mémoire partagée ... ?

par katagoto » 06 août 2009, 15:07

Je vais peut-être dire une bêtise, mais, je m'en suis jamais servit, quel est le soucis avec l'usage des webservice ? De mémoire c'est suffisamment soft pour ce que tu compte faire, je sais que Nagol l'a déjà dit mais ça me parait étrange que ça soit passé sous silence.

Pour ta dernière question, ça va dépendre du nombre de données que tu as, de la complexité des informations à faire passer et des performances que tu exige.
A et B ont-ils des points communs ?

Re: Démon, socket, sandbox, mémoire partagée ... ?

par Hywan » 03 août 2009, 14:59

L'idée, ce serait de d'abord l'utiliser en développement, donc pas de problème avec les hébergeurs. C'est sur notre propre configuration.

En fait, on pourrait résumer le problème à : comment transmettre des ressources et des instances d'objets (avec références et tout le toutime) entre deux exécutions PHP.
L'idée de Memcache n'est pas bête, mais je demande si ça supporte les ressources. Je regarde pour réussir à gêler des objets (blague de geek : j'ai appelé ma classe Hoa_Serialize_Cryonicable :-P). Mais il me faudrait pouvoir faire des implémentations ou héritages dynamiques …
C'est pas super hackable PHP en fait …

Sinon, si je me rabas sur une serialisation toute bête, je tape sur le client/serveur. Et là : base de données ou fichiers (même si au final, tout est fichier … on évite les blagues hein ;-)) ?

Re: Démon, socket, sandbox, mémoire partagée ... ?

par Sékiltoyai » 03 août 2009, 14:42

Ouais :)
Que ce soit le client ou au serveur, les deux ont les mêmes problèmes de sécurité. Les deux, tu dois protéger l'accès. par exemple à coup de chiffrage RSA ou DSA. Et dans tous les cas, tu ne pourras faire rien de tout cela de base sur un hébergement. Pour les serveurs, je vois mal un hébergeur admettre de laisser la possibilité d'en créer.
Bref, la meilleure solution pour partager des données, c'est ce que l'on utilise depuis moult : des fichiers. Ca peut prendre plusieurs formes : Base de données lourde (MySQL, Orcacle), base de données dans des fichiers locaux (SQLite, BDB), voire même des fichiers gérés par toi. Tu lockes, tu lis, tu délockes. Tu lockes, tu écris, tu délockes. Pas de conflit. Avec un chiffrage derrière, là aussi c'est sécure.
Voilà, pour moi, si tu veux quelquechose de sécure et pas foireux, c'est plus par là qu'il faut aller…

Re: Démon, socket, sandbox, mémoire partagée ... ?

par Hywan » 03 août 2009, 14:35

Encore aucune idée. T'en as une toi :-P ?

Re: Démon, socket, sandbox, mémoire partagée ... ?

par Sékiltoyai » 03 août 2009, 14:20

On ne s'est pas compris.

Ce ne sont pas deux applications sur des serveurs différents : ce sera forcément sur le même serveur avec la stricte même configuration.

L'idée c'est de lancer une appli' (A) qui va écouter ce que fait l'autre (B). Donc A émet des messages dans le vide, et on branche n'importe quelle appli' A, A', A'' etc. pour récupérer les messages.
Dans ces messages, il peut y avoir des données comme des objets etc.
C'est bien ce que j'avais compris. Je n'en démords pas, c'est lourd… :-/
Et quand je parlais de Sandbox Sékil', je ne parlais pas du module runkit mais de créer un bac à sable, soit une machine virtuelle quoi. Un endroit où l'appli' se lance. PHP lance du PHP en gros.
mmh. J'aimerais bien savoir techniquement comment tu envisages ça.

Re: Démon, socket, sandbox, mémoire partagée ... ?

par mojorisin » 03 août 2009, 12:46

Bonjour,
personnellement j'opterais pour memCache. De plus cette solution te permettra (le cas échéant) de faire migrer une application sur un autre serveur sans avoir à réécrire grand chose (dans l'absolu une ligne de code :) )

Re: Démon, socket, sandbox, mémoire partagée ... ?

par Hywan » 03 août 2009, 11:38

On ne s'est pas compris.

Ce ne sont pas deux applications sur des serveurs différents : ce sera forcément sur le même serveur avec la stricte même configuration.

L'idée c'est de lancer une appli' (A) qui va écouter ce que fait l'autre (B). Donc A émet des messages dans le vide, et on branche n'importe quelle appli' A, A', A'' etc. pour récupérer les messages.
Dans ces messages, il peut y avoir des données comme des objets etc.

Et quand je parlais de Sandbox Sékil', je ne parlais pas du module runkit mais de créer un bac à sable, soit une machine virtuelle quoi. Un endroit où l'appli' se lance. PHP lance du PHP en gros.

Re: Démon, socket, sandbox, mémoire partagée ... ?

par Nagol » 02 août 2009, 03:10

Des données transitants par des flux xml ?

(Oui et alors si j'ai envie :))

Bye Hawk
xml capue

le soucis avec xml c'est que ca occasionne énormément de travail de parsing (bon ça à la limite c'est pas grave ca reste très performant quand meme), ca gonfle les données qui transitent et ca limite donc les quantités de données transmissibles (ca c'est en revanche beaucoup plus génant et m'a pénalisé un bon nombre de fois dans mes diverses expériences profesionelles), l'alternative light du moment c'est json, mais json est très faible quand il s'agit de garantir que les données envoyés après transmission soit structurellement (en terme de typage) identifuqes, les objets se transforment en tableau et inverssement, c'est moche. c'est pour ça que serialize/unserialize qui est un algo redoutablement simple en définitive s'avère etre le meilleur à mon avis, ca garranti les données, c'est portable dans la mesure ou on se casse les dents à coder ce qu'il faut dans un autre langage et c'est petit sur le réseau.

Re: Démon, socket, sandbox, mémoire partagée ... ?

par thehawk » 02 août 2009, 01:18

Des données transitants par des flux xml ?

(Oui et alors si j'ai envie :))

Bye Hawk

Re: Démon, socket, sandbox, mémoire partagée ... ?

par Nagol » 01 août 2009, 20:36

webservice et serialize/unserialize mais on en a déja parlé sur irc :)

par Calimero » 31 juil. 2009, 23:59

Sékil++. Pas grand chose à ajouter...

Ah si une chose. Finalement dans tous les cas étudiés, le problème de la sérialisation des données reste entier, il ne faut donc pas que ça te bloque...