¿Cuál es la mejor arquitectura para puentear a XMPP?

Question

Si tengo un sistema independiente con su propio concepto de usuarios y presencia, ¿cuál es la arquitectura más adecuada para crear un puente hacia una red de servidores XMPP?Por lo que puedo decir, hay tres formas principales:

1. Actuar como servidor.Esto crea un punto de contacto, pero me temo que tiene implicaciones para la compatibilidad y potencialmente crea complejidad en mi sistema para emular un servidor.

2. Actuar como clientes.Esto parece implicar que necesito una conexión por usuario en mi sistema, lo que simplemente no se ampliará bien.

3. He oído hablar de un protocolo de puerta de enlace XMPP, pero no está claro si es mejor que la solución del cliente.Tampoco puedo decir si esto es estándar o no.

Cualquier sugerencia o compensación será apreciada.Por ejemplo, ¿alguna de estas soluciones requeriría ejecutar código dentro del servidor XMPP de destino (probablemente no sea algo que pueda hacer)?

Answer 1

El protocolo de puerta de enlace XMPP del que ha oído hablar probablemente tenga que ver con transportes.Un transporte es un servidor que se conecta tanto a un servidor XMPP como a un servidor que no es XMPP.Al ejecutar un transporte, puedo usar mi cliente Jabber para hablar con alguien que use, por ejemplo, MSN Messenger.

Un transporte normalmente se conecta una vez a la red remota por cada JID que considera en línea.Es decir, es tu opción 2 a la inversa.Esto se debe a que no existe una relación especial entre el transporte y la red que no es XMPP;el transporte actúa simplemente como un grupo de clientes habituales.Para que esto funcione, los clientes XMPP primero deben registrarse con el transporte, proporcionando credenciales de inicio de sesión para la red remota y permitiendo que el transporte vea su presencia.

La única razón por la que esto tiene posibilidades de escalar mejor es que puede haber muchos transportes para la misma red remota.Por ejemplo, mi servidor Jabber podría ejecutar un transporte a MSN, otro servidor Jabber podría ejecutar otro, y así sucesivamente, cada uno de los cuales proporcionaría conexiones para un subconjunto diferente de usuarios de XMPP.Si bien esto distribuye la carga en el lado de Jabber, y el equilibrio de carga en su sistema también puede distribuir la carga, aún requiere muchas conexiones entre los dos sistemas.

En su caso, debido a que (supongo) el lado que no es XMPP está cooperando, colocar una interfaz de servidor XMPP en el servidor que no es XMPP es probablemente su mejor opción.Esa interfaz de servidor es más adecuada para administrar el mapeo entre los JID de XMPP y cómo aparecerá ese JID en su propia red, en lugar de obligar a los usuarios de XMPP a registrarse, etc.

En caso de que no los hayas visto, puede que te resulten útiles:

• http://www.jabber.org/jabber-for-geeks/technology-overview
• http://www.xmpp.org/protocols/
• http://www.xmpp.org/extensions/

Espero que ayude.

Answer 2

Yo también estoy trabajando en un sistema similar.

Voy con la ruta de puerta de enlace/componente.He mirado varias opciones y me he decidido por esta.

La puerta de enlace es básicamente un componente con el propósito específico de conectar Jabber/XMPP con otra red.Tendrás que construir la mayoría de las cosas que das por sentado cuando usas XMPP como cliente.Cosas como el control de la lista.

Hay muy poca ayuda en línea sobre el diseño y la construcción reales de un componente.Al igual que la respuesta anterior, descubrí que los protocolos/extensiones xmpp son de ayuda.Siendo los principales:

• Cliente Básico 2008
• Servidor básico 2008
• Cliente Intermedio 2008
• Servidor intermedio 2008

Leerlos le mostrará qué XEP se espera que pueda manejar.Ignore las cosas que manejará el servidor al que se conectará su componente.

Es una pena que Djabberd tenga una documentación tan deficiente, ya que su sistema de "todo es un módulo" daba la posibilidad de que el backend del servidor pudiera interactuar directamente con la otra red.No logré avances en esto.

Answer 3

Básicamente, existen dos tipos de conexiones de servidor a servidor (s2s).El primero se llama puerta de enlace o transporte, pero son lo mismo.Probablemente este sea el tipo que estás buscando.No pude encontrar documentación específica para el lado que no es XMPP, pero cómo piensa XMPP acerca de hacer traducciones a servidores heredados está en http://xmpp.org/extensions/xep-0100.html.El segundo tipo realmente no se explica en ningún XEP adicional: son conexiones XMPP s2s normales.Busque "Comunicación de servidor a servidor" en RFC 3920 o RFC 3920bis para obtener el último borrador de actualización.

Dado que usted tiene sus propios usuarios y presencia en su servidor, y no es XMPP, los conceptos no se asignarán completamente al modelo XMPP.Aquí es donde entra en juego el trabajo del transporte.Tienes que hacer la traducción de tu modelo al modelo XMPP.Si bien esto requiere algo de trabajo, usted puede tomar todas las decisiones.

Lo que nos lleva directamente a una de las opciones de diseño clave: realmente necesita decidir qué cosas va a asignar a XMPP desde su servicio y cuáles no.Estas descripciones de características y casos de uso impulsarán la estructura general.Por ejemplo, ¿es esto como un transporte para hablar con los servicios de chat de AOL o MSN?Luego necesitará una forma de asignar su equivalente en listas, presencia y mantener la información de la sesión junto con los inicios de sesión y contraseñas de sus usuarios locales al servidor remoto.Esto se debe a que su transporte deberá hacerse pasar por esos usuarios y deberá iniciar sesión en nombre de ellos.

O tal vez sea solo un puente s2s hacia el juego de ajedrez basado en XMPP de otra persona, por lo que no necesita iniciar sesión en el servidor remoto y puede actuar de manera similar a un servidor de correo electrónico y pasar la información de un lado a otro.(Con conexiones normales de s2s, la única sesión que se almacenaría sería la autenticación SASL utilizada con el servidor remoto, pero a nivel de usuario, s2s solo mantiene la conexión y no la sesión de inicio de sesión).

Otros factores son la escalabilidad y la modularidad de su parte.Resolvió algunas de las preocupaciones sobre la escalabilidad.Eche un vistazo a la instalación de varios transportes para equilibrar la carga.Para lograr modularidad, vea dónde desea tomar decisiones sobre qué hacer con cada paquete o acción.Por ejemplo, ¿cómo se maneja y realiza un seguimiento de los datos de suscripción?Puedes ponerlo en tu transporte, pero eso dificulta el uso de varios transportes.O si toma esa decisión más cerca de su servidor central, puede tener transportes más simples y usar algún código común si necesita hablar con servicios distintos a XMPP.La compensación es un servidor central más complejo con mayor potencial de vulnerabilidad.

Answer 4

La arquitectura que debe utilizar depende del sistema que no sea XMPP.

1. ¿Utiliza un sistema que no sea XMPP?En caso afirmativo, debería encontrar una manera de agregar una interfaz XMPP-S2S a ese sistema; en otras palabras, hacer que actúe como un servidor XMPP.AOL está utilizando este enfoque para AIM.Desafortunadamente, han restringido su acceso a GoogleTalk.

2. No opera el sistema que no es XMPP, pero tiene una interfaz de federación que puede usar: i.mi.su puerta de enlace puede comunicarse con el otro sistema como servidor y tiene un espacio de nombres propio.En este caso, puede crear una puerta de enlace que actúe como servidor federado en ambos lados.Porque no conozco ningún ejemplo de puerta de enlace que utilice este enfoque, pero podría usarlo si desea crear un puente público de XMPP a SIP.

3. Si el sistema que no es XMPP no le brinda una interfaz de federación, entonces no tiene otra opción que actuar como un grupo de clientes.En el mundo XMPP, esto se llama "transporte".Las diferencias entre un transporte y un servidor normal son básicamente:

   • los JID del transporte se asignan desde otro sistema (p. ej.john.doe\40example.net@msngateway.example.org - ¡realmente feo!)
   • Los usuarios de XMPP que deseen utilizar el transporte deben crear una cuenta en un sistema que no sea XMPP y proporcionar las credenciales de inicio de sesión de esa cuenta al servicio de transporte.El protocolo XMPP incluso tiene una extensión de protocolo que permite a los usuarios de XMPP realizar registros de transporte dentro de banda.

Answer 5

Otro enfoque es trabajar con el proveedor de su servidor XMPP.La mayoría tiene API internas que hacen posible la inyección de presencia desde aplicaciones de terceros.Por ejemplo, JabberXCP proporciona una API para esto que es realmente fácil de usar.

(Divulgación:Trabajo para Jabber, Inc, la empresa detrás de Jabber XCP)