Pergunta

Se eu tiver um sistema separado com conceito próprio de usuários e presença, qual a arquitetura mais adequada para criar uma ponte para uma rede de servidores XMPP?Pelo que posso dizer, existem três maneiras principais:

  1. Atue como um servidor.Isso cria um ponto de contato, mas temo que tenha implicações na compatibilidade e potencialmente crie complexidade em meu sistema para emular um servidor.

  2. Agir como um cliente.Isso parece implicar que preciso de uma conexão por usuário em meu sistema, o que simplesmente não será bem dimensionado.

  3. Já ouvi falar de um protocolo de gateway XMPP, mas não está claro se ele é melhor que a solução do cliente.Também não sei dizer se isso é padrão ou não.

Quaisquer sugestões ou compensações serão apreciadas.Por exemplo, alguma dessas soluções exigiria a execução de código dentro do servidor XMPP de destino (provavelmente algo que eu possa fazer).

Foi útil?

Solução

O protocolo de gateway XMPP do qual você já ouviu falar provavelmente tem a ver com transportes.Um transporte é um servidor que se conecta a um servidor XMPP e a um servidor não XMPP.Ao executar um transporte, posso usar meu cliente Jabber para falar com alguém usando, digamos, o MSN Messenger.

Um transporte normalmente se conecta uma vez à rede remota para cada JID que ele vê como online.Ou seja, é a sua opção 2 ao contrário.Isso ocorre porque não existe um relacionamento especial entre o transporte e a rede não XMPP;o transporte está simplesmente agindo como um grupo de clientes regulares.Para que isso funcione, os clientes XMPP devem primeiro registrar-se no transporte, fornecendo credenciais de login para a rede remota e permitindo que o transporte visualize sua presença.

A única razão pela qual isso tem chance de escalar melhor é que pode haver muitos transportes para a mesma rede remota.Por exemplo, meu servidor Jabber poderia executar um transporte para o MSN, outro servidor Jabber poderia executar outro e assim por diante, cada um fornecendo conexões para um subconjunto diferente de usuários XMPP.Embora isso distribua a carga no lado do Jabber e o balanceamento de carga em seu sistema também possa distribuir a carga, ainda requer muitas conexões entre os dois sistemas.

No seu caso, porque (presumo) o lado não-XMPP está cooperando, colocar uma interface de servidor XMPP no servidor não-XMPP é provavelmente sua melhor aposta.Essa interface de servidor é mais adequada para gerenciar o mapeamento entre JIDs XMPP e como esse JID aparecerá em sua própria rede, em vez de forçar os usuários XMPP a se registrarem e assim por diante.

Caso você não tenha visto estes, você pode achá-los úteis:

Espero que ajude.

Outras dicas

Eu também estou trabalhando em um sistema semelhante.

Eu vou com a rota gateway/componente.Analisei várias opções e decidi por esta.

O gateway é basicamente um componente com a finalidade específica de conectar o Jabber/XMPP com outra rede.Você terá que construir a maioria das coisas que você considera certas ao usar o XMPP como cliente.Coisas como controle de escalação.

Há muito pouca ajuda on-line sobre o projeto e a construção reais de um componente.Como a resposta acima, descobri que os protocolos/extensões xmpp ajudam.Os principais são:

A leitura deles mostrará quais XEPs você deverá ser capaz de lidar.Ignore as coisas que serão tratadas pelo servidor ao qual seu componente estará conectado.

É uma pena que o Djabberd tenha uma documentação tão pobre, já que seu sistema de "tudo é um módulo" dava a possibilidade de o backend do servidor poder fazer interface diretamente com a outra rede.Não fiz nenhum progresso nisso.

Existem basicamente dois tipos de conexões de servidor para servidor (s2s).O primeiro é chamado de gateway ou transporte, mas são a mesma coisa.Este é provavelmente o tipo que você está procurando.Não consegui encontrar documentação específica para o lado não-XMPP, mas como o XMPP pensa em fazer traduções para servidores legados está em http://xmpp.org/extensions/xep-0100.html.O segundo tipo realmente não é explicado em nenhum XEP adicional - são conexões XMPP s2s regulares.Procure por "Comunicação Servidor-Servidor" na RFC 3920 ou RFC 3920bis para obter o rascunho da atualização mais recente.

Como você tem seus próprios usuários e presença em seu servidor, e não é XMPP, os conceitos não serão mapeados completamente para o modelo XMPP.É aqui que entra o trabalho do transporte.Você tem que fazer a tradução do seu modelo para o modelo XMPP.Embora isso seja trabalhoso, você pode tomar todas as decisões.

O que nos leva direto a uma das principais opções de design - você realmente precisa decidir quais coisas você mapeará para XMPP a partir do seu serviço e quais não.Essas descrições de recursos e casos de uso orientarão a estrutura geral.Por exemplo, isso é como um transporte para falar com os serviços de chat da AOL ou do MSN?Em seguida, você precisará mapear o equivalente a escalações, presença e manter as informações da sessão junto com logins e senhas dos usuários locais para o servidor remoto.Isso ocorre porque seu transporte precisará fingir ser esses usuários e fazer login para eles.

Ou talvez você seja apenas uma ponte s2s para o jogo de xadrez baseado em XMPP de outra pessoa, então você não precisa de um login no servidor remoto e pode apenas agir de forma semelhante a um servidor de e-mail e passar as informações de um lado para outro.(Com conexões s2s normais, a única sessão que seria armazenada seria a autenticação SASL usada com o servidor remoto, mas no nível do usuário, o s2s apenas mantém a conexão, e não a sessão de login.)

Outros fatores são escalabilidade e modularidade de sua parte.Você acertou em cheio algumas das preocupações de escalabilidade.Dê uma olhada em como colocar vários transportes para equilibrar a carga.Para modularidade, veja onde você deseja tomar decisões sobre o que fazer com cada pacote ou ação.Por exemplo, como você gerencia e controla os dados de assinatura?Você pode colocá-lo em seu transporte, mas isso dificulta o uso de vários transportes.Ou se você tomar essa decisão mais perto do seu servidor núcleo, poderá ter transportes mais simples e usar algum código comum se precisar se comunicar com outros serviços além do XMPP.A desvantagem é um servidor central mais complexo com maior potencial de vulnerabilidade.

A arquitetura que você deve usar depende do sistema não XMPP.

  1. Você opera o sistema não XMPP?Se sim, você deve encontrar uma maneira de adicionar uma interface XMPP-S2S a esse sistema, ou seja, fazê-lo funcionar como um servidor XMPP.AOL está usando essa abordagem para AIM.Infelizmente, eles restringiram seu acesso ao GoogleTalk.

  2. Você não opera o sistema não XMPP, mas ele possui uma interface de federação que pode ser usada - i.e.seu gateway pode se comunicar com o outro sistema como um servidor e tem um namespace próprio.Nesse caso, é possível construir um gateway que atue como um servidor federado em ambos os lados.Pois não conheço nenhum exemplo de gateway que use essa abordagem, mas você pode usá-lo se quiser construir uma ponte pública XMPP para SIP.

  3. Se o sistema não XMPP não fornecer uma interface de federação, você não terá outra opção a não ser agir como um grupo de clientes.No mundo XMPP, isso é chamado de “transporte”.As diferenças entre um transporte e um servidor normal são basicamente:

    • os JIDs do transporte são mapeados de outro sistema (por exemplo,john.doe\40example.net@msngateway.example.org - muito feio!)
    • Os usuários XMPP que desejam usar o transporte precisam criar uma conta no sistema não XMPP e fornecer as credenciais de login dessa conta ao serviço de transporte.O protocolo XMPP ainda possui uma extensão de protocolo que permite aos usuários XMPP fazer registros de transporte dentro da banda.

Uma outra abordagem é trabalhar com o fornecedor do servidor XMPP.A maioria possui APIs internas que possibilitam a injeção de presença de aplicativos de terceiros.Por exemplo, JabberXCP fornece uma API para isso que é realmente fácil de usar.

(Divulgação:Eu trabalho para a Jabber, Inc, a empresa por trás do Jabber XCP)

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top