WordPress peut-il être conçu pour prendre en charge les websockets?
Websockets sont une technologie de pointe branchée dans HTML5. En principe, vous pouvez ouvrir un WebSocket pour permettre une communication bidirectionnelle persistante avec un serveur Web. Le client (interface utilisateur) peut envoyer des messages spontanément et le serveur peut également envoyer des messages.
La technologie existante (JavaScript) nécessite que tout soit démarré par le client - le serveur ne peut rien envoyer au client que le client n'a pas demandé. Les scripts doivent donc constamment actualiser et redemander des données qui pourraient ne pas avoir changé. Les Websockets fonctionnent davantage sur une base " Push " et permettent aux nouvelles données de se retrouver à tout moment.
Malheureusement, la plupart (tout ce que je peux trouver, de toute façon) des implémentations websocket nécessitent une application serveur spécifique pour fonctionner. Les gens exécuteront Apache sur les ports 80 et 443 (http et https) et exécuteront un autre système (généralement Node.js) sur un autre port (à savoir 8000 ou 8080) pour gérer les demandes Websocket.
Cela fonctionne, évidemment, mais il présente certains inconvénients.
J'ai un plugin que je veux construire qui grandement bénéficierait de l'utilisation de websockets dans WordPress. Toutefois, si un utilisateur doit installer un deuxième serveur Web (généralement impossible pour les personnes partageant un hébergement), il ne fonctionnera pas comme un plugin.
Alors, pour ceux d'entre vous qui ont de l'expérience, comment rendriez-vous WordPress compatible avec les Websockets? Souhaitez-vous que WordPress gère la communication elle-même ou intégre un autre script de mini-serveur dans le plug-in? Si vous l'avez déjà fait, comment l'avez-vous accompli sans casser WordPress?
Ressources possibles?
21/09/11 Mise à jour
Bien que Apache (le serveur le plus couramment installé pour exécuter WP sur un hôte partagé) ne puisse pas vraiment gérer les websockets de manière native, je m'interroge sur une alternative. Plusieurs plugins (JetPack, par exemple) communiquent avec un service externe ou une API pour générer du contenu.
Stats demande du contenu à Automattic. Akismet envoie des données d'un serveur externe. Après la date limite, le contenu est soumis au moment de la publication. Quelques outils de référencement font la navette entre des systèmes externes.
Donc, au lieu de loger le code websocket dans un plugin WordPress, serait-il possible d'héberger un service websocket dans un emplacement central et de faire en sorte qu'une interface WordPress interagisse avec cela?
Les WebSockets utilisent le protocole Websockets WS: /example.com/yourscript.js et ouvrent une connexion synchrone, ce qui signifie que la connexion est maintenue ouverte et dédiée au navigateur.
les serveurs httpd, comme Apache2 (utilisé par la plupart des fournisseurs d'hébergement partagé) utilisent le protocole http: http://example.com/yourscript.js et ouvrent une connexion asynchrone, ce qui signifie qu'aucune connexion n'est maintenue ouverte entre le serveur et le navigateur. (Vous pouvez prolonger modestement les connexions ouvertes en définissant certains paramètres de configuration, mais en général, il est asynchrone.)
Comme vous pouvez l'imaginer, le maintien de connexions ouvertes entre le navigateur et le serveur consacre davantage de ressources de serveur à chaque connexion de navigateur. Par conséquent, les ressources de serveur sont plus astreignantes que de supprimer des connexions après chaque demande. Les fournisseurs d'hébergement partagé ne sont naturellement pas disposés à prendre en charge WS sur l'hébergement partagé.
Bien que mod_python puisse être installé sur certains hôtes partagés, permettant ainsi aux utilisateurs de votre plugin d'exécuter pywebsocket , la propre documentation de pywebsocket indique clairement que "pywebsocket est destiné à des tests ou à des expériences".
Ainsi, même si on peut imaginer un plugin regroupant du code python pour créer un serveur pywebsocket, étant donné le serveur Apache qui le supporte, je ne pense pas qu'il serait raisonnable de distribuer un plugin qui le ferait.
En réponse à votre mise à jour, à mon avis et sur la base des recherches que j'ai effectuées, ce serait la meilleure option. Il serait même préférable de créer le plug-in front-end et le service websocket externe afin de dialoguer avec les plug-ins et de facturer des frais pour que vous puissiez monétiser votre idée, si vous le souhaitez. Vous pouvez même fournir le code source du service websocket et créer un paramètre dans le plug-in pour définir l'emplacement (où le domaine/IP et le port) du service websocket.
Oubliez le "classique" Apache2 - Apache2-mpm-prefork - à cette fin. Apache2-mpm-event pourrait peut-être gérer cela, mais c'est expérimental. Apache2 n'étant pas basé sur des événements, le problème décrit par @marfarma existe. Vous aurez besoin d’un serveur Web événementiel pour ce type de service, par exemple cherokee ou nginx.
nginx peut être un réel avantage pour WordPress (car wordpress.com l’utilise également comme serveur) et peut, par exemple, envoyer des requêtes spécifiées à un service node.js.
Quelques exemples dans le sujet:
J'ai également fait un petit tutoriel pour l'installation de nginx + php-fpm + wordpress .
Une autre solution potentielle consiste à utiliser un fournisseur de sockets Web tiers. J'ai un peu joué avec Pusher (http://pusher.com/), il existe une API que vous pouvez exploiter qui pourrait bien fonctionner pour ce que vous faites. essaie de faire. J'ai réfléchi à la façon dont je pourrais l'utiliser dans mes propres sites WordPress.
Un inconvénient possible est que d’autres personnes essayant d’utiliser votre plugin devront également obtenir un compte Pusher pour que cela fonctionne. Il est beaucoup plus facile de travailler que d’installer votre propre serveur Web Sockets et de le maintenir, ce serait un avantage pour les autres personnes qui essaient d’utiliser votre plugin.
La réponse courte est: oui, c'est faisable. Je pourrais toutefois examiner quelque chose d'un peu plus distribué qu'un seul point d'échec VPS que vous hébergez. Peut-être envisager des systèmes EC2 à charge équilibrée ou un tel système? (Je suppose que vous avez un flux de revenus pour fournir de telles commodités. sourire )