O WordPress pode ser criado para suportar websockets?

Os Websockets são uma tecnologia moderna e de ponta, inserida no HTML5. Basicamente, você pode abrir um soquete da web para ativar a comunicação bidirecional persistente com um servidor da web. O cliente (interface do usuário) pode enviar mensagens espontaneamente e o servidor também.

A tecnologia existente (JavaScript) exige que tudo seja iniciado pelo cliente - o servidor não pode enviar nada ao cliente que o cliente não solicitou. Portanto, os scripts precisam estar constantemente atualizando e solicitando dados que podem não ter sido alterados. Os Websockets funcionam mais com base em " push " e permitem que novos dados sejam publicados sempre que possível.

Infelizmente, a maioria das implementações de websocket (tudo o que posso encontrar) exige um aplicativo de servidor específico para funcionar. As pessoas executam o Apache nas portas 80 e 443 (http e https) e executam outro sistema (normalmente Node.js) em outra porta (por exemplo, 8000 ou 8080) para lidar com solicitações de websocket.

Isso funciona, obviamente, mas tem algumas desvantagens.

Eu tenho um plug-in que quero criar que se beneficiaria muito com o uso de websockets no WordPress. Mas se um usuário precisar instalar um segundo servidor da Web (geralmente impossível para pessoas com hospedagem compartilhada), ele não funcionará como um plug-in.

Então, para qualquer um de vocês com experiência, como você tornaria o WordPress compatível com os websockets? Você faria o WordPress manipular a comunicação em si ou agrupar outro script de mini-servidor no plug-in? Se você já fez isso, como conseguiu isso sem quebrar o próprio WordPress?

Recursos possíveis?

• Servidor de soquete da Web extensível
• Websocket PHP
• PHP e Websockets

21/09/11 Atualização

Com toda a conversa sobre como o Apache (o servidor mais comumente instalado para executar o WP em um host compartilhado) não consegue lidar com os websockets nativamente, estou pensando em uma alternativa. Vários plug-ins (JetPack, por exemplo) conversam com um serviço externo ou API para gerar conteúdo.

Estatísticas solicita conteúdo da Automattic. O Akismet envia e volta dados de um servidor externo. Após o prazo final, o conteúdo é enviado no momento da publicação. Algumas ferramentas de SEO repassam as coisas através de sistemas externos.

Então, como uma alternativa para alojar o código do websocket em um plug-in do WordPress, seria possível hospedar um serviço do websocket em um local central e, em vez disso, ter um front-end do WordPress interagindo com ele?

Os WebSockets usam o protocolo websockets: WS: /example.com/yourscript.js e abrem uma conexão síncrona - o que significa que a conexão é mantida aberta e dedicada ao navegador.

httpd servidores, como apache2 (usados pela maioria dos provedores de hospedagem compartilhada) usa o protocolo http: http://example.com/yourscript.jse abrir uma conexão assíncrona - o que significa que nenhuma conexão é mantido aberto entre o servidor eo browser. (Você pode prolongar as conexões abertas, modestamente, definindo certos parâmetros de configuração - mas, em geral, é assíncrono.)

Como você pode imaginar, a manutenção de conexões abertas entre o navegador e o servidor dedica mais recursos do servidor a cada conexão do navegador e, portanto, cobra mais impostos dos recursos do servidor do que a remoção de conexões após cada solicitação. Os provedores de hospedagem compartilhada são compreensivelmente desinclinados para oferecer suporte ao WS na hospedagem compartilhada.

Embora alguns hosts compartilhados possam ter o mod_python instalado, permitindo que os usuários do plugin executem pywebsocket , a própria documentação do pywebsocket afirma claramente que "o pywebsocket é destinado a fins experimentais ou de teste".

Portanto, embora se possa imaginar um plug-in agregando código python para criar um servidor pywebsocket, dado um servidor apache que o suporta, não acredito que seja razoável distribuir um plug-in que o fez.

Em resposta à sua atualização, na minha opinião e com base na pesquisa que fiz, essa seria a melhor opção. Melhor ainda seria criar o plug-in front-end e criar o serviço websocket externo para conversar com os plug-ins e cobrar uma taxa por isso, para que você possa gerar receita com sua ideia, se quiser. Você pode até fornecer o código-fonte para o serviço websocket e criar uma configuração no plug-in para definir onde (qual domínio / IP e porta) o serviço websocket está localizado.

Esqueça o apache2 "clássico" - apache2-mpm-prefork - para essa finalidade. Talvez o apache2-mpm-event possa lidar com isso, mas é experimental. Como o apache2 não é orientado a eventos, o problema descrito por @marfarma existe. Você precisará de um servidor da Web orientado a eventos para esse tipo de veiculação, por exemplo, cherokee ou nginx.

O nginx pode ser um benefício real para o WordPress (como o wordpress.com também o usa como servidor) e pode proxy solicitações especificadas para um serviço node.js. por exemplo.

Alguns exemplos no tópico:

• Websockets no Nginx (com Socket.IO e Gevent)
• Proxy de um servidor websocket com nginx

Também fiz um pequeno tutorial para a instalação do nginx + php-fpm + wordpress .

Outra solução em potencial é usar um provedor de soquetes da web de terceiros. Eu brinquei um pouco com o Pusher (http://pusher.com/), há uma API na qual você pode aproveitar que pode funcionar bem para o que você precisa. está tentando fazer. Eu estive pensando em como eu poderia usá-lo em meus próprios sites WordPress.

Uma possível desvantagem é que outras pessoas que tentam usar seu plugin também precisam obter uma conta Pusher para fazê-lo funcionar. É muito mais fácil trabalhar do que instalar o seu próprio servidor Web Sockets e ter que mantê-lo; isso seria realmente uma vantagem quando se trata de outras pessoas que tentam usar o seu plugin.

Resposta curta é: sim, é factível. No entanto, posso procurar algo um pouco mais distribuído do que um único ponto de falha do VPS que você hospeda. Talvez veja alguns sistemas EC2 com balanceamento de carga ou algo assim? (Suponho que você tenha um fluxo de receita para fornecer essas conveniências. Sorriso )