Aplicativo de bate -papo ASP.NET usando o banco de dados para fila de mensagens

Question

Eu desenvolvi um aplicativo da Web de bate -papo que usa um banco de dados SQLServer para trocar mensagens.

Todos os clientes pesquisam a cada x segundos para verificar se há novas mensagens.

É óbvio que essa abordagem consome muitos recursos, e eu queria saber se existe uma maneira "mais barata" de fazer isso.

Eu uso a mesma abordagem para "presença": verificando quem está.

Answer 1

Para algo como um aplicativo de bate-papo em tempo real, eu recomendaria um cache distribuído com um apoio ao SQL. Por acaso eu gosto de memcachi com o provedor de NET da ENYIM, então eu faria algo como o seguinte:

1. Mensagem do usuário
2. O sistema grava mensagem para o banco de dados
3. O sistema grava mensagem para cache
4. Todos os usuários pesquisam cache periodicamente para novas mensagens

O apoio ao banco de dados permite pré-carregar o cache no caso de o cache ser limpo ou o aplicativo reiniciar, mas os bits funcionais dependem do cache na memória, em vez de pesquisar o banco de dados.

Answer 2

Sem usar um plug -in/extensão do navegador, como Flash ou Java Applet, o navegador é essencialmente uma ferramenta de comunicação única. A solicitação deve ser iniciada pelo navegador para buscar dados. Você não pode 'pressionar' os dados para o navegador.

Muitos aplicativos da web usando o método de pesquisa AJAX para simular um servidor 'push'. O truque é equilibrar o tamanho da frequência/dados com a largura de banda e os recursos do servidor.

Acabei de fazer uma simples observação para o Gmail. Ele faz uma pesquisa httppot a cada 5 segundos. Se não houver mudança de 'estado', o tamanho dos dados da resposta será de apenas alguns bytes (não incluindo os cabeçalhos HTTP). É claro que o Google tem enormes recursos de servidor e largura de banda, é por isso que mencionei: encontrar um bom equilíbrio.

Isso é "melhorar a experiência do usuário versus o recurso do servidor". Você pode precisar sair com uma maneira criativa de estratégia de votação, em vez de uma pesquisa direta a cada x segundos.

Por exemplo, se nenhuma atividade da parte A, pesquise a cada 3 segundos. Enquanto a parte A está digitando, pesquise a cada 5 segundos. Esta é apenas uma ilustração, você pode brincar com os números ou sair com um mais eficiente.

Por fim, a troca de dados. O desafio é encontrar uma maneira de passar no tamanho mínimo de dados para transmitir as mesmas informações.

meus 2 centavos :)

Answer 3

Se você estiver usando o SQL Server 2005, poderá procurar serviços de notificação. Concedido que isso bloquearia você no SQL 2005, pois os serviços de notificação foram removidos no SQL 2008, foi projetado para permitir que o SQL Server notifique os aplicativos do cliente de alterações no banco de dados.

Se você quiser algo um pouco mais escalável, pode colocar algumas bandeiras no registro dos usuários. Quando uma mensagem para o usuário entra em altere o bit para novas mensagens para true. Quando você lê as mensagens, mude para 0. O mesmo para quando as pessoas se inscrevem. Dessa forma, você está lendo um campo muito pequeno que tem uma boa chance de já estar em cache.

Faça o fluxo de trabalho estaria pronto. Se for 1, pegue as mensagens da tabela de mensagens. Se é 0 não faça nada.

Answer 4

Em asp.net 4.0 você pode Use o padrão de observador com objetos e matrizes JavaScript IE: Ajax JSON liga com jQuery e / / Pagemethods.

Você sempre terá que atingir o banco de dados para fazer uma análise sobre se há algum dado para retornar ou não. O truque será em tornar essas chamadas pequenas e retornará apenas dados quando necessário.

Answer 5

Existem duas soluções relacionadas embutidas no SQL Server 2005 e ainda estão disponíveis no SQL Server 2008:

1) Corretor de serviço, que permite que os assinantes publiquem leituras em filas (o comando de recebimento com espera ..). No seu caso, você deseja enviar sua mensagem através do banco de dados usando serviços de corretores de serviço em frente a essas filas, que poderiam ser captadas pelos clientes em espera. Não há pesquisa, os clientes em espera são ativados quando uma mensagem é recebida.

2) Notificações de consulta, que permite que um assinante defina uma consulta e as notificações de recebimento quando o conjunto de dados resultaria em executar essa consulta mudaria. Construídos no corretor de serviços, as notificações de consulta são um pouco mais fáceis de usar, mas também podem ser um pouco menos eficientes. (Não que as notificações de consulta e seus irmãos, as notificações de eventos sejam frequentemente confundidas com serviços de notificação (NS), o que causa preocupação porque o NS é decomposto em 2008, no entanto, as notificações de consulta e eventos ainda estão totalmente disponíveis e até aprimoradas no SQL Server 2008).