Una de las curiosidades de las aplicaciones de que dispone Facebook hasta la fecha es sus protocolos para el chat. Mientras que Whatsapp y la mayoría de sus competidores (salvo Telegram), emplean el protocolo XMPP, el chat de Facebook emplea el protocolo MQTT, ¿por qué?
Después de trabajar durante mucho tiempo con XMPP veo sus virtudes y sus carencias. La principal carencia diría que es su formato: XML; mientras que por un lado aporta la flexibilidad de los espacios de nombres, por otro es bastante costoso su análisis (o parsing). No obstante, la mayor carencia es la flexibilidad. Es curioso que XML aporte flexibilidad y sin embargo el protocolo en sí la limite. A través de varios XEP como el XEP-0198 se intenta hacer que el protocolo de inicio de sesión para temas como la reconexión sea más liviano.
No obstante, la llegada de MQTT y su uso por parte de Facebook, además de su soporte en sistemas como RabbitMQ hace pensar si no ha llegado la hora de revisar otros protocolos para este nuevo paradigma de comunicación en lugar de seguir adaptando y parcheando XMPP.
El recorrido de XMPP
XMPP nació antes de que los smartphones inundaran el mundo y cada uno pudiese tener uno junto con su conjunto de aplicaciones y entre ellas aplicaciones de mensajería instantánea. Los usos de XMPP se ceñían a aplicaciones de escritorio donde el usuario con una conexión fija se conecta y mantiene la conexión abierta hasta que decide apagar el ordenador o cerrar la aplicación.
Con la llegada de las aplicaciones móviles vemos otro entorno de trabajo completamente diferente como es la inestabilidad en la conexión a Internet. Uno de los puntos más pesados de XMPP es el inicio de sesión, como ya comenté y el hecho de que este se produzca cada vez que desbloqueamos el dispositivo móvil porque en modo bloqueado normalmente se cierran estas conexiones o cuando se cambia de WiFi a 3G o viceversa, hace que el dispositivo tenga que realizar la conexión y desconexión de forma frecuente.
Esto ha hecho que se piense en otro modo de conexión como BOSH donde en lugar de una conexión abierta y fija se emplea el encapsulado en HTTP y un identificador de sesión para no tener que abrir sesión cada vez.
Además, por la naturaleza de los dispositivos móviles, el hecho de perder la conexión hace que el servidor de XMPP pueda seguir enviando mensajes al dispositivo creyendo que éste aún está activo. Esto obliga a emplear técnicas como las descritas en el XEP-0184 (Delivery Receipts) o el XEP-0079 (Advanced Message Processing) para evitar la pérdida de mensajes.
¿En qué mejora MQTT?
El protocolo MQTT es simple. Su cabecera se compone tan solo de 2 bytes. Fue creado para el intercambio de mensajes de forma fiable entre sensores con una conectividad no confiable. Esto lo hace apropiado para el nuevo paradigma de comunicación de mensajería entre dispositivos móviles y de hecho, Facebook lo usa en su aplicación de chat.
Las mejoras con respecto a XMPP son:
- Mejora en el flujo y manejo de mensajes. El protocolo es binario y muy pequeño, cada mensaje contiene una cabecera de unos cuantos bytes y el contenido del mensaje en sí.
- Asegura la entrega. El protocolo tiene confirmación de entrega para cada mensaje enviado al cliente, por lo que asegura que un mensaje enviado desde la cola ha llegado a su destino.
- La reconexión no es un problema. Tanto el protocolo en sí como la autenticación son livianas, por lo que conectar/desconectar no se convierte en un problema.
¿Por qué quedarse con XMPP?
MQTT además de ser simple está orientado a la suscripción y la confirmación de envío, por lo que aporta seguridad en la recepción de los mensajes. No obstante, su protocolo no dispone de otros elementos como XMPP relacionados con la lista de contactos (o roster), permisos o seguridad referente a lo que puede enviar/recibir cada cliente.
Esto hace que un simple servidor con soporte de MQTT no nos sirva de mucho para realizar chat entre dispositivos de forma fiable, sino que tendríamos que desarrollar toda esa lógica a nivel de servidor para evitar que un cliente cualquiera pudiese publicar o suscribirse en cualquier cola.
Hay un ejemplo en Ruby de una aplicación de chat desarrollada para mostrar cómo se puede realizar un chat simple para el protocolo sin tener en cuenta seguridad, pero completamente funcional.
Conclusiones
Tanto en XMPP como en MQTT hay que realizar ajustes para adaptarlos al paradigma de conectividad móvil. El problema si decidimos emplear XMPP es resolver problemas como la pérdida de mensajes o el rendimiento en la conexión y reconexión. Sin embargo, con MQTT nos enfrentamos al hecho de tener que construir un sistema de lista de contactos y un servidor para dar funcionalidad extra además de aportar seguridad. No obstante, este servidor podría verse como otro cliente con muchos más privilegios que puede realizar el enrutado de cola a cola cada mensaje o solicitud que va recibiendo.
En definitiva, según lo que quieras hacer, puede convenirte emplear más uno u otro, dependerá del proyecto que tengas en mente.
¿Qué crees que podría adaptarse mejor a tu proyecto? ¿Quieres que lo averigüemos? ¡Comenta o contacta con nosotros!
