Servidor Websockets com tolerância a falhas e armazenamento de mensagens durável

Question

Estou começando a experimentar com websockets.

Alguém sabe de um servidor websockets (de código aberto ou pago) que fornece um armazenamento duradouro do "canal" do websocket? Todos os exemplos que encontrei não abordam a durabilidade - se um servidor websockets ficar inativo, todos os dados de "canal" serão perdidos.

Serviços como o Pusher não discutem realmente se abordam o problema da durabilidade (e ainda não recebi uma resposta do suporte técnico).

Feliz em apostar, mas prefiro não reinventar a roda.

EDITAR:

Eu não estou procurando informações sobre websockets 101. Isso está prontamente disponível e compreendido.

Estou à procura de um servidor (de código aberto ou pago) que suporte websockets e tenha um armazenamento durável para os dados do websocket para que, no caso de um servidor falhar, um novo servidor possa assumir onde o original foi deixado off.

Dois objetivos principais: 1. suporte a cenários de failover contemplados pelo Network Working Group link (o mais importante é que as mensagens perdidas são enviadas quando um cliente se conecta a um servidor de failover) 2. apoiar cenários onde novos assinantes devem receber todas as mensagens anteriores que foram publicadas.

Claro que isso pode ser feito na camada de aplicativo ... mas não é isso que estou procurando.

EDITAR

Assim, após algumas pesquisas, as seguintes opções instaladas parecem ser as mais robustas:

• Kaazing Migratory
• Migratório ( link )

Serviços hospedados que parecem "reais"

• Empurrador (excelente API, mas sem recurso histórico ainda)
• PubNub (tem histórico)

Todos os serviços acima têm fallback gracioso para outros métodos de comunicação se websockets não estiverem disponíveis.

Não consegui encontrar nenhum código-fonte aberto que oferecesse clustering "pronto para uso", failover e um armazenamento de mensagens durável para reproduzir o histórico. Existem alguns projetos que podem servir como bons pontos de partida, mas não exatamente o que estou procurando.

    

Answer 1

Assim, após algumas pesquisas, as seguintes opções instaladas parecem ser as mais robustas:

• Kaazing
• Migratório ( link )

Serviços hospedados que parecem "reais"

• Empurrador (excelente API, mas sem recurso histórico ainda)
• PubNub (tem histórico)

Todos os serviços acima têm fallback gracioso para outros métodos de comunicação se websockets não estiverem disponíveis.

Não consegui encontrar nenhum código-fonte aberto que oferecesse clustering "pronto para uso", failover e um armazenamento de mensagens durável para reproduzir o histórico. Existem alguns projetos que podem servir como bons pontos de partida, mas não exatamente o que estou procurando.

    

Answer 2

O Hornetq é um intermediário de mensagem geral que suporta JMS, STOMP e Websockets + Stomp. Ele fornece durabilidade de mensagens junto com vários outros recursos.

    

Answer 3

O que você quer dizer com dados do canal?

Deveria ser o dever de um aplicativo que é executado dentro do servidor para cuidar dos dados (pense LAMP).

Pense em quantos dados são salvos quando você cria um arquivo HTML com um formulário que posta em si e apenas o coloca em um apache simples. Todos os "dados de formulário" são perdidos após cada solicitação.

EDITAR:

Você está no caminho errado.

Websockets não têm relação com persistência ou durabilidade, nem SMTP, HTTP ou IMAP. É apenas uma descrição de transporte. (Heck, nem mesmo o syslog está falando sobre persistência no RFC)

Eu não sei o que você está procurando, mas tenho certeza que não é a durabilidade dos bytes enviados ou recebidos por um websocket, mas sim a durabilidade dos dados construídos após os bytes terem sido enviados.

Este problema foi resolvido algumas vezes, apenas referenciei as estruturas padrão do RDBMS:

• Hibernar (java)
• SQLAlchemy (python)
• ActiveRecord (ruby)

Se você enviar apenas o JSON, também poderá usar algum armazenamento não relacionado, como Riak, Redis, MongoDB, CouchDB.

É claro que cabe a você analisar os dados e criar algo que funcione para sua configuração. Eu odeio dizer isso, mas salvar o que é enviado por um websocket sem saber o significado disso é quase o mesmo que pegar um tcpdump e depois lê-lo com ed.

Posso sugerir a migração desta questão para o stackoverflow Não acho que o serverfault seja o local certo para a arquitetura e o desenvolvimento do framework.

    

Answer 4

Para resolver a parte da pergunta que pergunta se Pusher é durável, posso confirmar que, se um usuário que estava conectado ao serviço Pusher e ao WebSocket servidor que eles estavam conectados a morrer que eles seriam automaticamente reconectados a outro servidor WebSocket. Os dados do canal só existem no servidor WebSocket como dados transitórios e temos um sistema totalmente separado que permite que nossos servidores WebSocket distribuam e consumam informações de clientes conectados. No momento, não persistimos informações dentro do Pusher. Os dados são distribuídos simplesmente entre componentes conectados, como nossa API REST e clientes conectados.

No momento, se as mensagens fossem enviadas durante a reconexão de um cliente, esse usuário perderia essas mensagens. No entanto, estamos implementando o histórico do canal, o que significa que persistiremos nos dados dentro dos canais. Isso significaria que qualquer mensagem que um usuário tenha perdido poderá ser recuperada. Como nossos servidores WebSocket não lidariam com a persistência de dados se perdêssemos um servidor WebSocket, não perderíamos os dados do canal.

    

Answer 5

PubNub - link - fornece a durabilidade do canal automaticamente. Automático significa: Quando 3G / 4G / WiFi cai, ao reconectar mensagens perdidas são entregues; automaticamente. Isso é valioso para clientes móveis em trânsito com conexões de rede instáveis. Além disso, o PubNub fornece uma API para verificar o histórico de mensagens antigas enviadas.

O PubNub é gratuito e você não precisa se inscrever em contas para usá-lo. Existem recursos opcionais para pagamento disponíveis.

Confira o mais recente aplicativo para dispositivos móveis PubNub Powered em breve: link