Linux? - Page 136

pourquoi non adapté ?

à chaque demande de page qui n'est pas en cache, le site regarde si il à une page dédié, si oui il la délivre, sinon il transmet l'url à node, si node trouve une correspondance il renvois un json avec les info de la référence demandé et de ses "enfants" éventuels, le php ensuite va servir de moteur de template et mettre en forme les données

bref il peut très bien y avoir 200 requêtes simultanés

ca c'est pour 99% du boulot, la lecture,
pour l’écriture qui est elle réservé à l'admin oui je pourrais utiliser un fichier temporaire pour passer les données entre les deux, mais vu que la cible finale est le stockage dans redis je suis passé directement par lui

T'as raison robinhood, ils sont tous nuls à chier et codent comme des porcs ceux qui te disent ça

bah la communication inter process est tout nouveau pour moi j'essais de comprendre et de faire au plus simple ^^

il faut que je regarde les pipes

---

après si ce que disais Nil étais d'en fait ne pas me prendre la tête avec 2 process et remplacer le serveur node par un fichier,

bah c'est un choix, node ne quittant jamais il peut garder en mémoire une version évolué et déjà objet de toute les références et les servir très vite

en vrai stockage j'ai une entré avec l'arbre principal en json, (+ un arbre secondaire pour des "liens" de produit) et une entré par référence

node charge l'arbre et l'intégralité des produits,
il ajoute ensuite des propriété supplémentaires avec des info dépendantes du parsing des arbres (par exemple le vrai emplacement du produit pour l'url canonique)
ensuite il attend les requêtes et distribue des données prêtes à se faire afficher

(Sinon, pour la communication inter-process, tu peux aussi utiliser un web service ou assimilable)

Puisque c'est du local (2 processus tournant tous les 2 sur le serveur), as-tu pensé à D-Bus?
http://pecl.php.net/package/DBus

utiliser un tier ?

redis à bien un système de distribution de messages

c'est une solution mais bon je ne vais pas me reposer ailleurs car je n'y arrive pas ici ^^

http://www.zeromq.org/ et un des projets qui se basent dessus ?

robinHood (./4051) :
pourquoi non adapté ?

à chaque demande de page qui n'est pas en cache, le site regarde si il à une page dédié, si oui il la délivre, sinon il transmet l'url à node, si node trouve une correspondance il renvois un json avec les info de la référence demandé et de ses "enfants" éventuels, le php ensuite va servir de moteur de template et mettre en forme les données

bref il peut très bien y avoir 200 requêtes simultanés

ca c'est pour 99% du boulot, la lecture,
pour l’écriture qui est elle réservé à l'admin oui je pourrais utiliser un fichier temporaire pour passer les données entre les deux, mais vu que la cible finale est le stockage dans redis je suis passé directement par lui

L'UDP, c'est pour faire du réseau (tu n'en fais pas) en s'autorisant des pertes de paquets (tu ne le veux pas) et en se moquant de l'ordre des trames (ce n'est pas ton cas). Bref, ce n'est pas adapté.

Il y a plein d'autres méthodes de communication qui devraient mieux convenir.

un PIPE tout betement ?

pas assez hype le pipe !

badum, tss!

c'était pas le but, j'imagine que la tentative de mise en place d'un échange UDP réponds aussi à un souhait d'expérimentation, là où un pipe n'apporte pas de nouvelle expérience de dév...

Bah un pipe, il faut utiliser popen/pclose c'est pas les meme fonctions

Y'a également les FIFOs sous Linux qui peuvent être utilisées.

Bref des mécanismes d'IPC y'en a pléthore, et UDP est probablement l'un des moins bon choix possibles

shm aussi

je n'aime pas trop pratiquer les pipes mais quant il faut il faut, quitte à ce que cela te reste au travers de la gorge ©

pour revenir à l'udp, qui j'en suis sur n'est pas si diabolique que ca,
sachant qu'ici c'est en fichier, la perte de paquet n'est elle pas dans ce cas précis tout simplement *impossible* ?

edit >
sur cette question un gars répond

TCP doesn't do paths. TCP can connect to a (host,port) pair.

donc si je comprend bien, simplement me connecter sur un port au lieu du fichier va forcer le tcp et adieu les problèmes ?

Non.

non pour la perte de paquet ou pour le socket sur un port en tcp ? ou les deux ?

http://www.hacksparrow.com/tcp-socket-programming-in-node-js.html
c'est exactement la seconde syntaxe que j'ai mise plus haut .listen(port,host); et visiblement ca fait du tcp

robinHood (./4066) :
je n'aime pas trop pratiquer les pipes mais quant il faut il faut, quitte à ce que cela te reste au travers de la gorge ©

Hem...

Ha joli, ça valait la peine d'attendre

rh: ton problème c'est que tu controles pas ton API, tu ne semble même pas savoir clairement "ce que ça fait".
BTW ,

robinHood (./4049) :
surtout rapide entre deux process sur ma machine

1) passer par les stacks réseau n'est PAS rapide
2) même machine = utilise un mécanisme de mémoire partagé adapté au lieu du support réseau.

Tu dois vraiment absolument passer par ta merdouille en js? Sous linux je suis quasiment sûr qu'il y a une libjson si tu veux absolument ce format.

Il y a même beaucoup de libjson.

²

%D

"xkcd did it"

Et oui, hélas, les femmes tournent sur un système d'exploitation propriétaire…

oui mais elles nous ouvrent une fenêtre sur le monde. #loin#

Ooooooh c'est meuuuugnon !