Jul 14

XMPP amb BOSH: usant HTTP com a protocol de transport

This entry is part 2 of 4 in the series xmpp

Reading time: 4 – 7 minutes

La potència de treballar amb BOSH (Bidirectional-streams Over Synchronous HTTP) rau en que malgrat aparentment l’única forma que hi ha d’implementar XMPP sobre HTTP seria mitjançant tècniques de polling, o sigui, que periódicament el client anés connectant-se al servidor per preguntar si hi ha alguna nova informació per ell.

Doncs BOSH aconsegueix millorar aquest algoritme i el que intenta descriure és quelcom així:

  1. El client fa una connexió ‘HTTP request’ al servidor
  2. El servidor no envia cap resposta, així doncs, la connexió no es tanca.
  3. Quan el servidor té una informació (asíncrona) a enviar al client, llavors busca alguna connexió oberta del client i que estigui esperant resposta, o sigui, qu estigui al punt 2. Llavors el que fa és enviar l’informació a través d’aquesta connexió com una ‘request response’. La connexió es tanca.
  4. Un cop el client rep l’informació inmediatament després de tancar-se l’enllaç, aquest torna a obrir una connexió contra el servidor, o sigui, tornem al punt 1.

Obviament quan el client té alguna cosa a enviar això es fa en el punt 1.

A l’hora de la veritat els servidors de Jabber/XMPP el que tenen per oferir accés via BOSH és un especie de proxy que rep les connexions HTTP i les processa tal com he explica més amunt, per l’altre costat captura els events que rep de cada un dels clients XMPP que esta instanciant i va connectant els fluxes de dades que rep a través d’XMPP als sockets HTTP que té esperant informació.

Servidors BOSH incrustats en servidors XMPP

Obviament això ens porta a pensar, que podem usar un servidor BOSH per un servidor XMPP que no el suporti a mode de proxy. Això es podria programar de forma força senzilla amb twisted, per altre banda, hi ha servidors XMPP que ja suporten de serie el servidor BOSH, alguns exemples són: ejabberd, Tigase, Openfire i Jabber XCP.

Avantatges de tenir el servidor BOSH dins del servidor XMPP:

  • Sovint esta més ben testejat que el codi que podem fer-nos o que ha desenvolupat un tercer per fer aquesta tasca.
  • A priori hauria de ser més eficient, ja que la part de recepció d’events/senyals es fa a través de l’API nativa i no pas d’un client XMPP. Cosa que permet estalviar recursos i ser més eficient en la seva tasca.
  • És més fàcil de configurar, sovint només cal descomentar la línia corresponent del fitxer de configuració i llestos.

Com que no tot podien ser avantatges aquí van els inconvenients:

  • Un servidor BOSH que esta incrustat en un servidor XMPP obviament només pot atendre les peticions que van cap aquell servidor, per tant, si volem que això sigui escalable haurem de montar un balencejador de càrrega sobre el port HTTP per anar desviant connexions entre diferents sevidor BOSH.
  • El suport del servidor BOSH esta lligat al suport que la comunitat doni al servidor XMPP amb el que va lligat, això no sempre és suficient.

Quan no hem de suportar més d’un servidor XMPP, i a més aquest ja suporti BOSH no hi ha hauran mai problemes. La cosa es complicarà quan haguem d’escalar aquesta infraestructura.

Servidors BOSH dedicats, per tant independents del servidor XMPP

Per exemple: Punjab, Araneo, JabberHTTPBind i rhb. Pel que fa les avantatges i desavantatges d’aquest tipus de servidors BOSH, obviament són les mateixes que les anteriors però invertides.

Un servidor BOSH dedicat, per tant, podrà connectar-se a una xarxa XMPP a través d’un servidor XMPP federat sense problemes. Sovint el preu de sobrecarrega que això suposa esta més que justificat. Cal pensar que per cada client s’hauran de tenir sovint dues connexions TCP/HTTP més una connexió TCP/XMPP; per tant, tres sockets oberts per cada client connectat al servidor BOSH. Amb això suposo que queda clara la similitut amb un servidor proxy, no?
Com ja he apuntat abans escalar els servidors BOSH a través de ‘load-balancers’ és molt senzill, per exemple ús recomano nginex. Penseu que amb aquest ‘load-balancer’ podem tenir fins a10.000 connexions HTTP i només consumir 2’5Mb de memòria RAM. Per tant, aquesta també és una molt bona raó per usar-los externs els servidors BOSH. De fet, això no només ho penso jo sinó que aquí també ho pensen: BOSH cloud.
De fet, hi ha gent tan agoserada que gosa dir que XMPP és millor si els clients usen BOSH per accedir-hi, de fet, si llegeixes el raonament no sembla tan dolent: XMPP is better with BOSH.

Nota final

Per si algú encara no ho tenia clar, això és el que usen les llibreries d’XMPP implementades en JavaScript, o sigui, els client de xat (Jabber/XMPP) que via Web. Per exemple, el client que podem usar des de la pàgina web de gmail.

Obviament les aplicacions Jabber/XMPP són infinites i no només com a clients de xat. Per tant, podeu aprofitar aquestes llibreries JS que implementen BOSH per mostrar de forma interactiva a les vostres interficies web qualsevol tipus de contingut que obtingueu a través de la xarxa XMPP.

May 01

XMPP: introducció

This entry is part 1 of 4 in the series xmpp

Reading time: 5 – 8 minutes

Definició

XMPP Standards Foundation
XMPP (Extensible Messaging and Presence Protocol) és un protocol estàndard i obert que es basa en l’intercanvi de missatges XML. Inicialment va ser concebut per implementar xarxes de missatgeria instantànea (IM) però actualment s’usa per un ventall de funcionalitats molt més ampli. Qualsevol aplicació que necessiti un sistema de missatges entre diferents mòduls distribuits és sensible a usar XMPP per ntercanviar missatges usant aquesta tecnologia com a middleware. Potser les eines més conegudes que usen XMPP com a middleware són Jabber, GTalk i les funcions de videoconferència i audioconferència de la mateixa Google.

Les funcionalitats que ens ofereix el protocol són realment amplies i potents:

  • Rudundància
  • Escalavilitat
  • No calen VPNs per accedir al serveis dins d’una xarxa amb NAT
  • Suport SSL i Certificats
  • Backends on es guarden usuaris: MySQL, LDAP, etc.
  • Extensible (usa el que s’anomenen XEP)
  • BOSH permet usar XMPP sobre HTTP, cosa que per disseny del protol XMPP seria un problema.

Glossari

  • JID: els nodes d’una xarxa XMPP s’identifiquen a través d’aquest identificador, que és de la forma: user@domain/resource (exemple: miquel@servidor.cat/im). Tractament dels JID:
    • user@example.com – conegut com a JID
    • user@example.com/desktop – conegut com a JID o full JID
  • Stanza: els missatges XML que s’intercanvien entre un servidor XMPP i un client s’anomenen Stanzas.  Hi ha tres tipus d’stanzas:
    • Messages: transporten informació entre nodes, els missatges es poden organitzar en threads. N’hi ha de diferents tipus:
      • normal
      • chat
      • groupchat
      • headline
      • error
    • Presence: serveixen per informar de la dipsonibilitat d’un recurs (online/offline):
      • away
      • do not disturb
      • extended away
      • free for chat
    • IQ Stanza (info query): similar a un HTTP GET/POST/PUT, serveix per demanar informacions concretes a un node. Ideals per extendre el protocol. Per exemple, les IQ s’usen per saber quins recursos (usuaris) estan connectats a un canal de xat. N’hi ha de tres tipus:
      • get: demanen informació (HTTP GET)
      • set: proveeixen informació (HTTP POST/PUT)
      • result: retornen informació requerida o confirmen que s’ha acceptat una comanda ‘set’.
  • Extensibility: per tal de que sigui simple extendre el protocol, les stanzas suporten namespaces i qualsevol element XML d’una stanza es pot usar com un payload, per transportar: XHTML tags, Atom feeds, XML-RPCs, etc.
  • Roster: llista de persones que participen en un event.
  • Presence subscriptions: els recursos d’una xarxa (sovint els usuaris) poden subscriures a altres recursos (altres usuaris) per tal de saber si estan o no disponibles en cada moment.
  • Asincronisme: la gràcia del XMPP respecte altres protocols com HTTP és que es tracta d’un protocol asíncron, o sigui, que les connexions s’estableixen durant molt de temps i en qualsevol moment el servidor i/o el client poden enviar i rebre stanzas a través d’aquest canal. Els protocols HTTP estableixen connexions relativament curtes on sovint només hi ha una petició i una resposta després es tanca la connexió.

Polling vs PubSub

Aquest és el gran parigma de les estructures client servidor actuals, sovint els servidors tenen informacions que són pels seus clients. Però per disseny els servidors no podenen connectar amb els seus clients i han d’esperar a que aquests es connectin per donar-los la informació que necessiten. Això dona lloc al que coneixem com a polling, o sigui, que els clients periódicament han d’anar connectant als servidors per saber si tenen quelcom nou per ells. Un bon exemple per entendre això és els servidors POP3 els servidors tenen una serie de correus enmagatzemats a l’espera que els clients a través del seu MUA es connectin per descarregar-se el correu.

Doncs bé en una xarxa XMPP, els clients es troven connectats al servidor en tot moment i tenen establer un canal permanent (real o virtual) entre clients i servidors. Per tant, l’intercanvi d’informació és bidireccional i qualsevol d’ambdues parts port enviar i rebre stanzas sense haber d’establir un nou canal, sinó que aprofiten el que ja tenen. PubSub és la capacitat que tenen els recursos d’XMPP (clients d’XMPP) de subscriures i publicar qualsevol informació, la possibilitat de subscriures a una informació permet que cada cop que el servidor té una informació d’aquell tipus l’enviarà directament al client sense que aquest l’hagi de demanar. Un exemple per entendre millor el PubSub seria el que fan els usuaris al unir-se a un canal de xat; o sigui, informen al servidor que volen rebre qualsevol informació que es publiqui al canal i el servidor quan algún usuari publica una nova informació al canal l’envia automàticament a la resta d’usuaris.

Com és fàcil imaginar XMPP ens dona usa serie d’avantatges per tota una serie d’aplicacions que altres protocols no poden, potser la més poderosa és la que es tracta aquí. Donant un cop d’ull als pros i contres:

Pros (PubSub > Polling)

  • Intercanvi bidireccional d’informació, no cal establir VPNs ni altres sistemes similars perquè hi hagi accés transparent entre servidors i clients.
  • Optimització del canal, no es malgasta ampla de banda fent preguntes per saber si hi ha algo nou, directament rebem les novetats.

Contres (PubSub < Polling)

  • Cal mantenir el canal establert, de forma real o virtual, això no sempre és possible o senzill. Per això apareixen tècniques/protocols com BOSH per permetre-ho.
  • XMPP no esta optimitzat per intercanviar grans volums d’informació.

La extenció més coneguda: Jingle

És una extenció d’XMPP que permet enviar missatges de senyalització entre recursos (clients) d’aplicacions multimèdia interactives com veu o video. Va ser dissenyat per Google i la XMPP Standards Foundation. El contenigut multimèdia s’envia a través d’RTP(Real-time Transport Protocol) amb ICE(Interactive Connectivity Establishment) per tal de poder traspassar els NAT(Network Address Translation).

Fonts

Wikipedia:

Web:

Presentació: