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

preguntas sobre aws (5)

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

Actúa como un 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.
Actúa como un cliente Esto parece implicar que necesito una conexión por usuario en mi sistema, que simplemente no va a escalar bien.
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).

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, la mejor opción es poner una interfaz de servidor XMPP en el servidor que no sea XMPP. 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 que no los haya visto, puede encontrarlos útiles:

Espero que ayude.

Yo también estoy trabajando en un sistema similar.

Voy con la ruta de entrada / 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. Los principales son:

Leer a través de estos le mostrará qué XEPs 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 pobre como su sistema de "todo es un módulo", que dio la posibilidad de que el servidor backend pudiera conectarse directamente a la otra red. No hice ningún progreso en esto.

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.

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

Básicamente, hay dos tipos de conexiones de servidor a servidor (s2s). 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.

Como 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 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 solo sea un puente de s2s para 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 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 del 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 lado. 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.

La arquitectura que debe usar depende del sistema que no es XMPP.

¿Opera 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.
No opera el sistema que no es XMPP, pero tiene una interfaz de federación que puede usar; es decir, 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.
Si el sistema que no es XMPP no le proporciona una interfaz de federación, entonces no tiene otra opción más 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 (por ejemplo, john.doe / [email protected] - ¡realmente feo!)
- Los usuarios de XMPP que deseen 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.