Discussion :

[Grégory PLANCHAT]

Bonjour,

Je suis à la recherche d'une extension PHP qui permettrait de mettre en place un serveur réseau, mais sans avoir à gérer explicitement les sockets en PHP (en quelque sorte équivalent à Node.js).

L'idée serait que le script PHP n'aurait plus qu'à paramétrer l'instanciation et d'implémenter des méthodes pour gérer les protocoles des couches OSI 5 à 7.

Le but final est (entre autres) de pouvoir mettre en place un serveur WebSocket. Chaque connexion à ce serveur pourrait, d'une part notifier les autres d'un évènement particulier, et d'autre part le serveur pourrait nativement partager des objets entre toutes ces connexions.

J'ai déjà créé une implémentation en PHP avec ext_socket, mais l'API de ce module est difficile à exploiter efficacement.

PS : le serveur web interne de PHP présent à partir de la version 5.4 est transparent pour les scripts PHP et il ne peut pas être exploité pour ce besoin.

Merci.

Greg

[Benjamin Delespierre]

Je ne comprends pas bien pourquoi essayer de travestir PHP pour un besoin pour lequel il n'est absolument pas conçu est plus intéressant qu'utiliser une technologie 1000x plus adaptée comme Java ou NodeJS ??

[grunk]

Si c'est uniquement pour les websocket tu peux jeter un oeil sur : http://socketo.me/

[Grégory PLANCHAT]

Je ne comprends pas bien pourquoi essayer de travestir PHP pour un besoin pour lequel il n'est absolument pas conçu est plus intéressant qu'utiliser une technologie 1000x plus adaptée comme Java ou NodeJS ??

Javascript a évolué pour devenir un langage système/serveur avec NodeJS, V8 (plus anciennement avec Rhino). Java, Python, Rails et Perl font du web depuis un certain temps sans que ça ne choque personne.

Pourquoi PHP devrait-il se cantonner à de la génération de HTML alors que des fonctions du langage ou des API introduites avec les versions successives de PHP 5 ne sont pas toutes présentes dans la majorité des langages cités?

@grunk : merci pour ce lien, c'est typiquement le genre d'API que je recherche, mais implémentée en C, dans une extension PHP.

[Benjamin Delespierre]

Javascript a évolué pour devenir un langage système/serveur avec NodeJS, V8 (plus anciennement avec Rhino). Java, Python, Rails et Perl font du web depuis un certain temps sans que ça ne choque personne.

Pourquoi PHP devrait-il se cantonner à de la génération de HTML alors que des fonctions du langage ou des API introduites avec les versions successives de PHP 5 ne sont pas toutes présentes dans la majorité des langages cités?

Parce que PHP à été créé au départ comme un pré-processeur hypertexte (d'ou son nom), son mode de fonctionnement se prête assez mal aux exercices que tu veux lui voir faire. Le cas de JavaScript est différent, ECMAScript n'est pas un langage web à proprement parler: c'est un langage destiné à fournir du scripting à une application hôte comme un navigateur, un serveur d'application ou même un jeu. JavaScript peut donc être utilisé dans d'autres contexte que celui du web, PHP quand à lui n'a que deux modes de fonctionnement: en CLI et en Web au sein d'un serveur web.

C'est pour cela que vouloir réaliser un serveur d'application avec PHP va à l'encontre de sa nature. On ne démonte pas un pneu avec une cuillère et on ne bois pas sa soupe avec un démonte-pneu, simple question de bon sens.

[Grégory PLANCHAT]

Ce sont de curieuses réponses pour quelqu'un qui implémente de la programmation orientée prototype en php alors que les classes, interfaces, traits et closures utilisés ensemble permettent de faire bien plus. Tu fais des essais toi-même, mais tu me donnes l'impression de rester fermé aux idées des autres dès qu'elles sortent du cadre que tu t'es fait de PHP. J'espère au moins me tromper sur ce point.

Une extension permet déjà de créer des socket BSD pour un serveur depuis au minimum PHP 4.1, voire peut être avant sous la forme d'une extension PECL.

PHP a été créé pour générer des pages HTML, il a évolué pour servir de langage de script système en mode CLI. Un serveur réseau est un script CLI, je ne déroge pas à la règle que tu as inventée plus haut.

Quoi qu'il en soit, j'ai des besoins spécifiques qui ne peuvent pas être résolus par une solution qui utiliserait Node, à moins de réécrire l'ensemble de mon application en javascript, avec un résultat incertain.

[gene69]

perso j'ai pas de démonte pneu, du coup j'utilise des cuillères à soupe et ça marche assez bien.

Grégory, je serai totalement de ton avis SI on n'avait pas un problème majeur en php, c'est a dire: pas de thread, pas de fork.

[stealth35]

J'ai exactement ce qu'il te faut : PHP UV

https://github.com/chobie/php-uv
http://chobie.net/presentations/php-uv/index.html

[Grégory PLANCHAT]

perso j'ai pas de démonte pneu, du coup j'utilise des cuillères à soupe et ça marche assez bien.

Grégory, je serai totalement de ton avis SI on n'avait pas un problème majeur en php, c'est a dire: pas de thread, pas de fork.

J'ai déjà fait beaucoup de recherches sur comment trouver une solution équivalente à Node.js en PHP et je reste convaincu que PHP a de quoi donner sur ce terrain.

Node.js n'utilise pas de thread, tout est géré de manière asynchrone. Ca impose au départ une petite gymnastique intellectuelle pour réorganiser l'architecture et les développements d'une manière différente, mais c'est très simple à mettre en place. Dans le pire des cas, si je tenais à gérer des threads sous Unix, il existe PCNTL, mais ce n'est pas mon but ici : tout est plus compliqué avec des threads.

Avec mysqli+mysqlnd depuis PHP 5.3, les accès à MySQL peuvent être asynchrones http://php.net/manual/en/mysqli.poll.php, c'était le premier gros obstacle à tout ce projet de serveur d'application.

J'ai aussi fait des recherches sur l'extension PECL libevent pour gérer des évènements lancés par des changements de statuts de descripteurs de fichiers, il me reste à tester si cette extension fonctionne avec l'extension Socket de PHP ou en ouvrant un stream TCP et si le résultat est efficace. Je venais ici pour demander des retours d'expérience sur une extension que je ne connaitrais pas.

D'où ma question de départ, avant de me lancer dans une exploration du fonctionnement de toutes ces extensions, si une API permettrait de gérer une instance de serveur où seules les couches OSI 5 à 7 seraient à implémenter. Si l'API était orientée objet ça serait un plus, mais je ne suis pas trop difficile.

@stealth35 : à quoi correspond PHP UV? Il est marqué sur le readme du dépôt Github qu'il est expérimental et donc que l'API est instable. Est-ce que tu as plus d'informations à ce sujet?

[stealth35]

@stealth35 : à quoi correspond PHP UV? Il est marqué sur le readme du dépôt Github qu'il est expérimental et donc que l'API est instable. Est-ce que tu as plus d'informations à ce sujet?

c'est la libuv pour PHP, la libuv c'est ce qu'utilise NodeJS pour les IO

de tout façon dans tous les cas, il va falloir lancer un serveur en continue, donc le PHP n'est pas grand intérêt la dedans

[Grégory PLANCHAT]

c'est la libuv pour PHP, la libuv c'est ce qu'utilise NodeJS pour les IO

de tout façon dans tous les cas, il va falloir lancer un serveur en continue, donc le PHP n'est pas grand intérêt la dedans

Ok, merci.

PHP a de l'intérêt. Apache, Nginx et consorts en ont beaucoup moins. L'application n'est pas vouée à tourner sur un serveur mutualisé.

[stealth35]

Utiliser PHP pour faire ça n'a aucun intérêt, si n'est de faire du PHP pour faire du PHP, pourquoi ne pas utiliser NodeJS ?

[Benjamin Delespierre]

Ce sont de curieuses réponses pour quelqu'un qui implémente de la programmation orientée prototype en php alors que les classes, interfaces, traits et closures utilisés ensemble permettent de faire bien plus. Tu fais des essais toi-même, mais tu me donnes l'impression de rester fermé aux idées des autres dès qu'elles sortent du cadre que tu t'es fait de PHP. J'espère au moins me tromper sur ce point.

Ce que je fais pour m'amuser n'a rien à voir avec ce que j'utilise dans le milieu professionnel

Quoi qu'il en soit, j'ai des besoins spécifiques qui ne peuvent pas être résolus par une solution qui utiliserait Node, à moins de réécrire l'ensemble de mon application en javascript, avec un résultat incertain.

Un bridge à base de webservices serait peut être plus approprié

Enfin, jettes un oeil à php-uv ça m'a l'air d'être assez proche de ton besoin.

[gene69]

de memoire, php n'a jamais eu un GC performant parce justement il n'était pas executé en continu, je parle des versions < php 5.3. il parait que c'est mieux maintenant mais je serai interessé de savoir si c'est pas une limitation.

[stealth35]

de memoire, php n'a jamais eu un GC performant parce justement il n'était pas executé en continu, je parle des versions < php 5.3. il parait que c'est mieux maintenant mais je serai interessé de savoir si c'est pas une limitation.

http://www.php.net/manual/fr/feature...iderations.php

[Grégory PLANCHAT]

J'ai contacté le développeur de php-uv qui me conseille d'utiliser Ratchet et react-php. Il prévoit de publier php-uv en beta sur PECL cet été, mais il ne prévoit aucune interface orientée objet pour le moment par manque de temps pour la tester.

Ce que je fais pour m'amuser n'a rien à voir avec ce que j'utilise dans le milieu professionnel

On a donc un point commun

[Lunixinclar]

Je suis à la recherche d'une extension PHP qui permettrait de mettre en place un serveur réseau

Salut PHP dispose de l'appel système select().
J'ai écrit pas mal de serveurs en C (serveurs de chat, jeux vidéos, jeu d'échec, vidéoconférence, etc...) et sincèrement si je devais le faire en PHP ce serait avec select.

[Grégory PLANCHAT]

Bonjour,

Merci pour ta réponse.

Oui, la première implémentation que j'ai fait utilise l'extension socket et la fonction socket_select(), mais je trouve l'API de cette extension pas très pratique.

Les valeurs présentes dans les tableaux sont des ressources PHP brutes, rien ne peut y être attaché, pas même un identifiant de connexion qui permettrait simplement et rapidement de retrouver un objet qui gère cette connexion (pour la gestion de session par exemple).

Le problème se résout avec un appel à array_search, mais ca ne me parait ni optimal, ni pratique.