Si estás leyendo esto seguro que alguna vez has utilizado un “chat”. Los encontramos de las maneras más variopintas, desde desde simples chats de dos personas (punto a punto se podría llamar), en páginas webs con decenas de personas, el ya bastante obsoletillo IRC, el malvado MSN Messenger…. alguno incluso habrá infectado a alguien con un troyano el cual trae una herramienta de chat para hablar con tu víctima. Como ves, existen infinidad de herramientas y cada una con sus normas y sus características. Yo os voy a hablar del sistema definitivo, un sistema potente, estandar y sobre todo libre. Saludemos a XMPP.

¿Qué es XMPP y por qué usar XMPP?

Es un protocolo. Como a muchos eso os dejará igual voy a tratar de explicar que es esto y te darás cuenta del por qué es necesario que sea libre.

En informática un protocolo son una serie de normas para que dos máquinas sean capaces de entenderse. Esto nos da la posibilidad de que dos (o más) máquinas (o programas dentro de una máquina) puedan compartir información, dialogar entre ellas, discutir y llegar a acuerdos, etc. Sí, las máquinas hablan entre ellas, y mucho. Son unas cotorras de tomo y lomo lo que pasa es que no nos damos cuenta. Nosotros sólo vemos el resultado de toda era “burocracia” entre máquinas. Aquellos que nos siguen desde hace bastante igual se acuerdan de la dramatización que hicimos sobre el protocolo DNS, pues esto es igual. Cuando dos máquinas conocen el protocolo son capaces de trabajar conjuntamente pero si una usa un protocolo extraño pues le costará encontrar otras máquinas con la que trabajar. Un símil entre protocolo y cerrado y abierto con la realidad sería el siguiente. Quieres aprender un idioma, vas a una academia donde te dan unas clases pero tienes la posibilidad de ir a la biblioteca pública y coger libros para aprenderlo mejor. También puedes buscar por internet e incluso preguntar a gente que gustosamente te ayudará (siempre y cuando no seas muy cansino claro ). En resumidas cuentas, nadie te pondrá trabas a que aprendas ese idioma.

En cambio, si quieres aprender un idioma pero para conocerlo tienes que entrar en una secta y no hay ningún libro ni persona fuera de esa secta que habla sobre el idioma pues lo vas a tener bastante complicado. Esto equivale a un protocolo cerrado.

Quizá te ronda por la cabeza que ¿Quién en su sano juicio querría usar un protocolo cerrado? Pues en su sano juicio supongo que muy pocos pero el problema es que los usamos sin saberlo (la ignorancia, ese gran arma de los “poderosos”). Como estamos hablando de protocolos de mensajería instantánea os voy a poner un ejemplo de este tipo que seguro que conoces: MSN Messenger. Es un protocolo cerrado y sucio. También si te hablo de uno que usa XMPP igual te suena, GTalk. Podría iniciar un flame war diciendo lo malos que son los de Microsoft y lo bien que me caen los de Google pero eso ya para otro día.

Una duda que puede surgir es que si el protocolo de MSN Messenger es cerrado, ¿Cómo hay tantos programas libres ajenos a la secta que lo “entienden”? En informática esto se llama ingeniería inversa. Consiste en capturar mensajes y volver a enviarlo. observar qué pasa y al cabo de muchas horas ir comprendiendo cómo funciona. Un símil sería como irte a china sin saber nada de chino. Con el tiempo acabarás aprendiendo el idioma (que remedio) relacionando palabras que dicen con acciones que hacen luego. Nunca aprenderás chino como si te explicaran la gramática y todo eso, pero acabarás aprendiendo lo suficiente como para manejarte. Y con el ejemplo de la secta, como un día se le ocurra cambiar cosas del idioma nos han fastidiado. Nos toca volver a hacer todo el trabajo.

Requiere de mucho más tiempo comprender un protocolo de esos que hacer un programa que use el protocolo. De ahí que sea tan importante que el protocolo sea libre, que a nadie le gusta perder el tiempo.

Todo esto de poner facilidades para que los demás te entiendan puede llevar a otra cuestión. ¿Y si no quiero que nadie sepa lo que estoy comunicando? Por ejemplo, yo no quiero que sepan lo que hablo con la gente. Me alegra que me hagas esa pregunta
Eso no forma parte del protocolo sino del canal. No voy a explicarlo porque no viene a cuento pero la solución es usar un canal seguro que en resumidas cuentas en cifrar la información. He de decir que el que un protocolo sea cerrado no es sinónimo (ni mucho menos) de seguridad. La información viaja intacta. Mientras el protocolo cerrado de microsoft es totalmente inseguro (ya que no va cifrado) el xmpp siendo libre es totalmente seguro ya que sí va cifrado. Esto lo demostramos un día cuando crackeamos nuestro wifi y sabíamos lo que hablaba por el messenger. Eso con xmpp no hubiera sido posible (cuantas referencias estoy haciendo hoy). Creo que han quedado explicados los puntos “Qué es” y “Por qué usarlo”. Pasemos a centrarnos en XMPP.

Cómo funciona XMPP

XMPP funciona a base de enviar XML. XML es una manera estándar de enviar información y que a día de hoy está hasta en la sopa aunque, de nuevo, no nos demos cuenta. Por ejemplo, el HTML (lo de las páginas web) es XML. Voy a explicar brevemente como va esto del XML (es realmente sencillo)

<cosa atributo1=valor1>Cotenido</cosa>

la palabra “cosa” se denomina tag e indica el tipo de elemento que es. El resto de campos son bastantes intuitivos. Un ejemplo real de mensaje XMPP sería el siguiente

<message from="maxpowel@wixet.com" to="prueba@wixet.com">Ey tío que pasaaaa</message>

Sobra explicarlo pero esto envía un mensaje de maxpowel@wixet.com a prueba@wixet.com con el contenido “Ey tío que pasaaa”

En XMPP existen 3 tipos de elementos diferentes: message, presence e iq
Message: Son los mensajes que se envían los usuarios entre sí.
Presence: Los eventos de presencia de usuarios. Cuando se desconectan o conectan, cuando cambian de estado, de nombre….
Iq: Sirve para enviar comandos internos. Por ejemplo para iniciar una nueva conexión, informar de errores y cosas que no tienen nada que ver con los usuarios.

Pero antes de poder conectarte te tienes que conectar, verdad? Eso se hace al principio (qué listo) y en este proceso el cliente y el servidor negocian a través del protocolo cómo se sincronizarán, el cifrado que usarán y todas esas cosas.

En el título comentaba algo de BOSH. Eso de BOSH es una pasarela para poder establecer una conexión a un servidor XMPP desde HTTP. Esto es necesario por lo siguiente.
XMPP es una conexión persistente. Se mantiene la conexión desde el principio hasta el final, y mientras se envían todos los mensajes que quieran.
HTTP es una conexión de petición y respuesta. Esto es que tu te conectas y haces una petición. El servidor responde y se termina la conexión.

Con este método haces una petición y estas a la espera de que el servidor responda y en ese momento lanzas otra. Hay otro método (polling) que consiste en enviar muchas peticiones cortitas (cada medio segundo por ejemplo) pero personalmente prefiero la primera.
Esta tarea requiere de una pequeña sincronización. Esta sincronización se hace mediante un numerito que le pasamos en cada petición y que se debe ir incrementando después de cada respuesta NO vacía, luego explico que es eso.

Siempre debemos tener una conexión abierta hacia el servidor. Podemos conectarnos al servidor de dos maneras:
Enviando una petición nuestra (por ejemplo queremos enviar un mensaje a un contacto) o escuchando (nos quedamos escuchando al servidor hasta que nos diga algo).
Sólo podemos tener dos conexiones abiertas y en caso de abrir una tercera o un numero de sincronización incrementado incorrectamente provocada que finalice la sesión (el servidor nos llama violadores y nos manda a paseo).
Voy a explicar qué es un mensaje vacío y la relación que tiene con el número de sincronización. El numerito en cuestión se llama RID y debe ser generado de manera aleatoria. Es importante tener un buen algoritmo que genere un número lo más difícil posible de precedir ya que teniendo el RID junto al SID (un numero que identifica la conexión y se crea en ese momento) alguien podría hacerse pasar por nosotros ya que si envias un SID y un RID correcto la cosa va a funcionar (al ser por HTTP el servidor no tiene manera de conocer de dónde viene la petición). Describo un ejemplo.

Inicio sesión y estoy a la escucha de un mensaje del servidor. Estoy usando una conexión.
Decido que a mi amigo “Prueba” quiero saludarle así que le escribo “Hola”. Esto genera un objeto message que se envía al servidor. En este instante estoy usando dos conexiones. Si se me ocurre enviar otra cosa el servidor nos cerrará sesión y adiós muy buenas. Lo que se debe hacer en este momento es cerrar la primera conexión, que devolverá un mensaje vacío. Entonces NO tenemos que incrementar el RID.
Nuestro amigo Prueba nos responde diciendo “Eyyyy” y el servidor nos lo hace saber, creando un message y a través de la conexión creada nos lo envía. Como dije antes, en HTTP una vez recibida la respuesta se finaliza la conexión. En este momento debemos lanzar una petición para escuchar pero como sí recibimos un mensaje incrementamos el RID. Si no lo hacemos ya sabes lo que pasa. Remarco que mensaje no es lo mismo que message. Message es un tipo de mensaje como también lo es presence o iq.

Esa es la parte complicadilla. Conceptualmente no es complejo ni mucho menos pero crear un algoritmo pues ya tiene algo de tela. Si os interesa saber más hice un plugin jQuery (en javascript) y que en apenas 200 líneas es capaz de manejar ese protocolo y facilitar manejadores de eventos. Puedes ver un poco de documentación en

1. Como configurar Google Talk en pidgin Pidgin, para el que no lo conozca, es un cliente...