XMPP amb BOSH: usant HTTP com a protocol de transport
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í:
- El client fa una connexió ‘HTTP request’ al servidor
- El servidor no envia cap resposta, així doncs, la connexió no es tanca.
- 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.
- 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.
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.
Tuning d’un servidor MySQL
Aquesta última setmana he tingut alguns problemes de rendiment amb un servidor MySQL, de fet, hi havia en concret una taula que tenia fins a 53 milions de registres, malgrat el seu espai tampoc era tan gran al voltant de 4Gb l’accés de lectura i escriptura a la taula era molt lent, sobretot per funcions de filtrat una mica complexes.
Doncs bé, coses que he aprés que potser ús poden anar bé són:
- Cal habilitar les ‘slow_query_logs’ i tenir indexats tots els camps que apareixen després dels WHERE’s, això millora considerablement el rendiment.
- Cal incrementar el innodb_log_file_size fins a un 25% del valor del innodb_buffer_pool_size; això redueix considerablement el temps d’escriptura.
- Usar JFS, com a sistema de fitxers del directori ‘data’ del MySQL. És substancialment més ràpid que el ext3. Exemples de rendiment.
- Posar els logs en un disc dedicat, diferent del disc que té les dades.
- Usar el paràmetre ‘noatime’ en la partició que conté les de dades del MySQL.
- Deshabilitar la partició de SWAP, usar un ‘innodb buffer spool’ ben gran, sempre pensant amb la RAM disponible.
- Montar els directori temporal de MySQL sobre una partició RAM.
- Reduir el key_buffer size a 1-2Mb si no s’usen taules MyISAM.
- Usar el kernel 2.6 amb SMP amb processador multi-cos, és especialment important per aplicaions multithread com el MySQL.
- Usar RAID0 (stripped disks) i usar un servidor de replicació per les còpies de seguretat. Millora els temps d’I/O del disc, com és lògic.
Ja som tients, aquí teniu l’Abril i la Bruna
Demà ja faran una setmaneta i ja les tenim a casa, perdó ja les tenen. No ús confongueu que no són filles nostres. Només arribem al mèrit de tiets “ficticis”. O sigui, que són les filles del Xavi i la Sabina dues preciositats que van neixer el dia 27/6/2009 a Sant Joan de Deu (Barcelona).
De fet, tinc moltes altres fotos que ahir varem intercanviar amb el Xavi, però encara no l’he pogut organitzar i encara menys pujar al servidor d’internet. Així que pels ‘mussols’ que les volgueu veure en foto haureu d’esperar una miqueta.
llibre: “La economía Long Tail”
Almenys fa tres setmanes que tinc pendent escriure una ressenya sobre aquest llibre “La econmía Long Tail: De los mercados de masas al triunfo de lo minoritario” (ISBN: 978-84-934642-6-4) escrit per Chris Anderson (editor de la revista Wired). Per cert, el llibre me’l va recomanar el Jordi, així doncs li he d’agraïr que ho fes perquè desconeixia totalment el concepte ‘long tail’ i ara el veig a tots els racons.
Pels que com jo tampoc ús soni el terme, una bona forma d’intrudir-se és a partir de l’article de la wikipedia sobre el conepte. De fet, hi ha ben pocs conceptes que donin tan de si i que es poguin explicar amb algo tan senzill com aquesta gràfica:
El concepte ‘long tail’ faria referència a la part dreta de la gràfica, o sigui, on la gràfica tendeix a zero però mai arriba a ser-ho per molt a la dreta que anem. Aquí és on rau el valor de la teoria. Posaré un exemple, perquè s’entengui millor.
Imagineu que la gràfica aplica al index de ventes de DVDs; doncs bé, a l’esquerra tindriem els ‘top’, el que més es ven. A la dreta, tota la ‘long tail’ amb milions i milions de DVDs que pertanyen a infinitat de nitxols de mercat que són més o menys grossos, però que sovint si ens n’anéssim a la posició 100.000 d’aquest llistat de ventes de DVD trobariem que aquest DVD es continua venent encara que sigui en molt poques unitats, igualment segueix passant a la posició 500.000 o 1.000.000. El que preten demostrar la teoria del ‘long tail’ és que hi ha empreses com pot ser Netflix, Rhapsody, iTunes o d’altres similars que sovint acaben fent tants o més diners per la suma de ventes a la ‘long tail’ que no pas en els productes ‘top’.
Més enllà del concepte, la valoració que faig del llibre és bona. Diguem que li poso un 7 sobre 10. Aconsegueix mantenir-te força enganxat malgrat com ja em va comentar el Jordi si haguessin fet un treball de síntesis amb 15 pàgines es podia explicar tot el que ve a dir el llibre. Però l’assaig demostra la teoria i explica com s’ha arribat a poder afirmar això, contrastant-ho en diversos aspectes de l’economia actual i del comerç electrònic. A més, cal destacar l’important treball de camp que fa l’autor per contrastar la teoria. Així doncs, si penseu fer algún tipus de pla de negoci que toqui internet ni que sigui de passada, és una bona lectura a fer.
compilar VMWare Workstation amb una FC11
Nota tècnica, per assegurar-se que tenim tot el que fa falta per compilar VMWare Workstation en una Fedora Core 11, executar com a root:
yum install kernel-devel kernel-headers gcc
yum groupinstall "Development Tools" "Development Libraries"En cas de que al fer un:
vmware-modconfig --console --install-allencara doni errors de compilació, a mi el que m’ha funcionat ha estat descarregar els fitxers:
després he executat altre cop el ‘vmware-modconfig’ i ja ha compilat, malgrat dona força warning tot ha funcionat bé.
Això ho he fet amb les versions:
- kernel: 2.6.29.5-191.fc11.i586
- VMware Workstation v6.5.1.126130
La solució l’he trobat al thread:[VMware] Compile kernel problem..
openssl: certificats autosignats de forma molt simple
Fins aquest matí cada vegada que necessitava crear-me certificats auto-signats (self-signed certificates) usava llarguíssimes llistes d’opcions amb l’openssl, però avui he descobert (digueu-me lent) que si descarregues el paquet d’OpenSSL i el desempaquetes dins del codi font hi ha un directori que es diu: easy-rsa.
Com es pot observar el nom ja dona moltes pistes, doncs bé, dintre d’aquest hi trobem encara un altre directori anomenat 2.0. Aquí dintre, hi ha un munt d’scripts que ens simplificaran moltíssim la vida a l’hora de crear certificats, com sempre en faig un resum en forma de cookbook.
-
- Editar el fitxer vars. Cal modificar el valor de les variables:
export KEY_COUNTRY="yourContry"
export KEY_PROVINCE="yourProvince"
export KEY_CITY="yourCity"
export KEY_ORG="myOwnOrg"
export KEY_EMAIL="user@domain.tld"-
- Després netegem el directori de claus perquè no hi hagi restes d’exemples:
./clean-all-
- Carreguem variables d’entorn del fitxer vars:
source ./vars-
- Creem una CA (Certificate Authority):
./pkitool --initca-
- Crear el certificat per un servidor:
# ./pkitool --server
# penseu que a vegades el common_name ha de ser el url_host del servidor, per exemple, en servidors https
./pkitool --server nom_servidor-
- Certificats per un client:
# ./pkitool
./pkitool nom_client-
- Certificat per un client enpaquetat amb PKCS12:
# ./pkitool --pkcs12
./pkitool --pkcs12 nom_client-
- Generar un fitxer DH (Diffie-Hellman)
./pkitool --build-dhNOTA: en cas de volgueu protegir les claus privades amb una clau simètrica per evitar que siguin usades per tercers persones podeu fer-ho afegint el paràmetre ‘–pass‘ a les comandes anteriors.
Les claus generades les podeu trobar al directori ‘easy-rsa/2.0/keys‘.
Pels que no tingueu massa per la mà el tema dels certificats posaré quatre notes sobre els fitxers creats:
- *.csr: Certificate Signing Request, petició de certificat que s’envia a una CA perquè ens el torni signat.
- *.crt: Certificat signat per una CA
- *.key: Clau privada del certificat, sovint s’acostuma a protegir amb una clau simètrica
- ca.crt: Certificat de la CA
- ca.key: clau privada del certificat de la CA.
Senzill, oi? diria que ja no teniu excusa per gestionar-vos vosaltres mateixos les claus SSL. Si ús calen d’altres funcions al directori esmentat hi ha molts altres scripts i el propi ‘pkitool‘, té força altres opcions molt interessants i igual de simples d’usar.