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

Question

Si tengo un sistema separado con su propio concepto de usuarios y presencia, ¿cuál es la arquitectura más adecuada para crear un puente a una red de servidor 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, que simplemente no va a escalar bien.

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

Cualquier sugerencia o compensación sería apreciada. Por ejemplo, cualquiera de estas soluciones requeriría la ejecución de código dentro del servidor XMPP objetivo (probablemente no sea algo que pueda hacer).

Answer 1

El protocolo de puerta de enlace XMPP del que ha oído hablar es más probable que lo haga 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 usa, digamos, MSN Messenger.

Un transporte normalmente se conecta una vez a la red remota para cada JID que ve como en línea. Es decir, es su opción 2 en reversa. Esto se debe a que no existe una relación especial entre el transporte y la red que no es XMPP; el transporte simplemente actúa como un grupo de clientes regulares. Para que esto funcione, los clientes XMPP primero deben registrarse con el transporte, dando 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 una posibilidad 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 proporcionando conexiones para un subconjunto diferente de usuarios de XMPP. Si bien esto extiende la carga en el lado de Jabber, y el equilibrio de carga en su sistema también puede extender la carga, todavía requiere muchas conexiones entre los dos sistemas.

En su caso, porque (supongo) que el lado no XMPP está cooperando, poner una interfaz de servidor XMPP en el servidor que no es XMPP es probablemente su mejor opción. Esa interfaz de servidor es la más adecuada para administrar la asignación entre JID XMPP y cómo aparecerá el JID en su propia red, en lugar de forzar a los usuarios de XMPP a registrarse, y así sucesivamente.

En caso de no haber visto éstos, es posible que sean de utilidad:

• 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 acceso/componente. Miré varias opciones y me conformé con esta.

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

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

• Basic Client 2008
• Basic Server 2008
• Intermediate Client 2008
• Intermediate Server 2008

Lectura a través de éstas le mostrará lo XEPs que se espera que sea capaz de manejar. Ignore las cosas que manejará el servidor al que se conectará su componente.

Es una lástima que Djabberd tenga una documentación tan pobre como su sistema de "todo es un módulo" dio la posibilidad de que el servidor back-end del servidor pueda conectarse directamente a la otra red. No hice ningún progreso en esto.

Answer 3

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

(Revelación: Yo trabajo para Jabber, Inc., la compañía detrás de Jabber XCP)

Answer 4

Hay básicamente dos tipos de servidor a servidor (S2S) conexiones. El primero se llama una puerta de enlace o un transporte, pero son lo mismo. Este es probablemente el tipo que estás buscando. No pude encontrar documentación específica para el lado no XMPP, pero cómo XMPP piensa en 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 regulares XMPP s2s. Busque "Comunicación de servidor a servidor" en RFC 3920 o RFC 3920bis para la última actualización del borrador.

Dado que 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 el trabajo del transporte. Tienes que hacer la traducción desde tu modelo al modelo XMPP. Si bien esto es un trabajo, puedes tomar todas las decisiones.

Lo que nos lleva directamente a una de las opciones de diseño clave: debe decidir realmente qué cosas va a asignar a XMPP de su servicio y cuáles no. Estas características y descripciones de 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 de listas, presencia y mantener la información de la sesión junto con los inicios de sesión y las contraseñas de los usuarios locales en el servidor remoto. Esto se debe a que su transporte deberá pretender ser esos usuarios y deberá iniciar sesión para acceder a ellos.

O tal vez es solo un puente s2s para el 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 adelante. (Con las conexiones s2s normales, 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. Has encontrado algunas de las inquietudes de escalabilidad. Eche un vistazo a poner en transportes múltiples para equilibrar la carga. Para la modularidad, vea dónde desea tomar decisiones sobre qué hacer con cada paquete o acción. Por ejemplo, ¿cómo manejas y haces un seguimiento de los datos de suscripción? Puedes ponerlo en tu transporte, pero eso hace que usar transportes múltiples sea más difícil. 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 que no sean XMPP. El trade off es un servidor central más complejo con más potencial de vulnerabilidad.

Answer 5

Qué arquitectura debe usar depende del sistema que no es XMPP.

1. ¿Utiliza el sistema que no es XMPP? En caso afirmativo, debería encontrar la 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 Google Talk.

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 construir una puerta de enlace que actúe como un servidor federado en ambos lados. No conozco ningún ejemplo de una puerta de enlace que utilice este enfoque, pero podría usarlo si desea construir un puente público de XMPP a SIP.

3. Si el sistema que no es XMPP no le proporciona 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 JIDs del transporte se asignan desde otro sistema -
   (por ejemplo john.doe \ 40example.net@msngateway.example.org muy feo!)
   • Los usuarios de XMPP que desean utilizar el transporte necesitan crear una cuenta en el sistema que no es XMPP y dar 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 en banda.