¿Se puede hacer WordPress para soportar websockets?

Los Websockets son una tecnología moderna y moderna envuelta en HTML5. Básicamente, puede abrir un websocket para permitir la comunicación persistente de 2 vías con un servidor web. El cliente (interfaz de usuario) puede enviar mensajes espontáneamente, y el servidor también puede enviar mensajes.

La tecnología existente (JavaScript) requiere que todo sea iniciado por el cliente - el servidor no puede enviar nada al cliente que el cliente no tiene solicitudes. Por lo tanto, los scripts deben actualizarse constantemente y volver a solicitar datos que podrían no haber cambiado. Websockets trabajan más en un " empuje base" y dejar que los nuevos datos vienen por el tubo cada vez.

Desafortunadamente, la mayoría de las implementaciones websocket (todo lo que puedo encontrar, de todos modos) requieren una aplicación de servidor específica para funcionar. Las personas ejecutarán Apache en los puertos 80 y 443 (http y https) y ejecutarán otro sistema (generalmente Node.js) en otro puerto (es decir, 8000 u 8080) para manejar las solicitudes de WebSocket.

Esto funciona, obviamente, pero tiene algunos inconvenientes.

Tengo un complemento que quiero construir que se beneficiaría enormemente del uso de websockets dentro de WordPress. Pero si un usuario necesita instalar un segundo servidor web (generalmente imposible para las personas con hosting compartido), entonces no funcionará como un complemento.

Entonces, para cualquiera de ustedes que tenga experiencia, ¿cómo haría que WordPress sea compatible con websockets? Habría que hacer WordPress manejar la comunicación en sí misma, o haz otra escritura mini-servidor en el plugin? Si ya ha hecho esto, ¿cómo lo logró sin romper WordPress?

Posibles recursos?

• Servidor de Web Socket extensible
• PHP Websocket
• PHP y WebSockets

21/09/11 actualización

Con todo lo que se habla de cómo Apache (el servidor más comúnmente instalado para ejecutar WP en un host compartido) realmente no puede manejar los websockets de forma nativa, me pregunto acerca de una alternativa. Varios complementos (JetPack, por ejemplo) se comunican con un servicio externo o API para generar contenido.

Stats solicita contenido de Automattic. Akismet envía datos de un servidor externo a otro. Después de la fecha límite, envía contenido en el momento de la publicación. Algunas herramientas de SEO pasan cosas de un lado a otro a través de sistemas externos.

Entonces, como alternativa a alojar el código websocket dentro de un complemento de WordPress, ¿sería factible alojar un servicio websocket en una ubicación central y tener una interfaz de WordPress interactuando con eso?

WebSockets utiliza el protocolo websockets: WS: /example.com/yourscript.js y abre una conexión síncrona, lo que significa que la conexión se mantiene abierta y dedicada al navegador.

Los servidores httpd, como apache2 (utilizado por la mayoría de los proveedores de alojamiento compartido) utilizan el protocolo http: http://example.com/yourscript.jsy abren una conexión asincrónica, lo que significa que no se mantiene abierta ninguna conexión entre el servidor y el navegador. (Puede prolongar las conexiones abiertas, modestamente, estableciendo ciertos parámetros de configuración, pero en general es asíncrono).

Como puede imaginar, mantener conexiones abiertas entre el navegador y el servidor dedica más recursos del servidor a cada conexión del navegador y, por lo tanto, es más exigente para los recursos del servidor que desconectar las conexiones después de cada solicitud. Es comprensible que los proveedores de alojamiento compartido no estén dispuestos a admitir WS en alojamiento compartido.

Si bien ciertos hosts compartidos pueden tener instalado mod_python, lo que permite a los usuarios de su complemento ejecutar pywebsocket , la propia documentación de pywebsocket establece claramente que "pywebsocket está destinado a pruebas o fines experimentales".

Entonces, si bien uno puede imaginar un plugin que agrupa el código de Python para crear un servidor pywebsocket, dado un servidor apache que lo admite, no creo que sea razonable distribuir un complemento que lo hiciera.

En respuesta a su actualización, en mi opinión y en base a la investigación que he realizado, esa sería la mejor opción. Aún mejor sería crear el complemento front-end y crear el servicio websocket externo para hablar con los complementos, y cobrar una tarifa por él para que pueda monetizar su idea, si lo desea. Incluso podría proporcionar el código fuente para el servicio websocket y crear una configuración en el complemento para establecer dónde (qué dominio / IP y puerto) se encuentra el servicio websocket.

Olvídese del "clásico" apache2 - apache2-mpm-prefork - para este propósito. Tal vez apache2-mpm-event podría manejar esto, pero es experimental. Como apache2 no está controlado por eventos, el problema descrito por @marfarma existe. Necesitará un servidor web controlado por eventos para este tipo de servicio, por ejemplo cherokee o nginx.

nginx puede ser un beneficio real para WordPress (ya que wordpress.com lo usa como su servidor también), y puede enviar solicitudes específicas a un servicio node.js, por ejemplo.

Algunos ejemplos en el tema:

• Websockets en Nginx (con Socket.IO y Gevent)
• Proxying un servidor websocket con nginx

También hice un pequeño tutorial para la configuración de nginx + php-fpm + wordpress .

Otra posible solución es usar un proveedor externo de sockets web, he jugado un poco con Pusher (http://pusher.com/) un poco, hay una API que puede aprovechar que podría funcionar bien para lo que usted estás tratando de hacer. He estado contemplando cómo podría usarlo en mis propios sitios de WordPress.

Una posible desventaja es que otras personas que intenten usar su complemento también tendrían que obtener una cuenta Pusher para que funcione. Es mucho más fácil trabajar con él que instalar su propio servidor Web Sockets y tener que mantenerlo, eso sería una ventaja cuando se trata de que otros intenten usar su complemento.

La respuesta corta es: sí, es factible. Sin embargo, podría buscar algo un poco más distribuido que un solo punto de falla VPS que aloja. ¿Tal vez mirar en algunos sistemas EC2 con equilibrio de carga o algo así? (Supongo que tiene un flujo de ingresos para proporcionar tales comodidades. Sonrisa )