Mar 08

reDuh: TCP sobre HTTP

Reading time: 1 – 2 minutes

La idea es força simple es tracta de transportar un fluxe TCP sobre d’una connexió HTTP convencional, fiexeu-vos que en aquest cas no estem parlant de proxies ni similars. Sinó de paquets TCP+HTTP que en la part de dades del HTTP tornen a implementar TCP, si fessim un petit esquema seria algo així:

+----+----+------+------+-----+------+
|... | IP | TCP | HTTP | TCP | DATA |
+----+----+------+------+-----+------+

Si realment teniu aquest interés montar reDuh és realment senzill, de fet, suporta servidors amb JSP, PHP i ASP. En escència l’únic que fa és usar aquests protocols per re-obrir una connexió TCP. Així doncs, al servidor on montem aquesta eina hem de tenir certs privilegis per poder obrir sockets des d’un script.
L’eina no és massa recomanable si pensem tenir fluxes de dades molt intensos, per exemple, senssions VNC. Però funciona prou bé si el que volem és transportar una sessió SSH o similar.

Mar 05

Terminals via Web (CLI via Web)

Reading time: 2 – 2 minutes

UPDATE 2017/1/18: I just discovered Wetty which is by far the best option that I found to have a Web Terminal completely easy to use and compatible with Linux terminals. I highly recommend it.

En l’article sobre Turnkey Linux vaig parlar sobre shellinabox, doncs bé per coses de l’atzar he descobert que no és l’únic sistema que preten donar accés a una sessió de shell a través d’una pàgina web.

De fet, les tres eines que he trobat són realment bones, així doncs si algú en sap alguna cosa més sobre elles que m’ho digui perquè no sé amb quina quedar-me:

  • shellinabox: emula un terminal VT100 i es llença com un dimoni que dona accés al host local a través del port que escollim, pot treballar amb o sense SSL.
  • ANYTerm: també suporta SSL però treballa a través d’Apache recolzant-se amb mod_proxy.
  • AJAXTerm: inspirat en ANYTerm però molt més simple d’instal·lar, ja que només depèn de python, o sigui, que treballa com a dimoni en el sistema on volem tenir la shell.

Mar 05

Proxytunnel: connecta un socket a través d’un proxy HTTP i HTTPs

Reading time: 2 – 2 minutes

Descrirure tècnicament el que fa proxytunnel és força senzill, ja que l’únic que fa és connectar l’entrada i sortides estàndard a través d’un socket que va del client al servidor a través d’un servidor proxy HTTP o HTTPs; soportant autenticació de diversos tipus en el servidor proxy.
Gràcies a aquesta funcionalitat tan simple es pot aplicar en infinitat de llocs, per exemple, com a backend d’OpenSSH per tal de poder fer connexions SSH a través d’un proxy HTTP. Això si el proxy haurà de suportar el mètode CONNECT.
Un cop ha establert la connexió amb l’extrem desitjat publica un port a través del qual ens podem connectar a través d’un client TCP convencional i enviar/rebre dades de l’altre extrem del túnel.
Quan treballem sobre proxies HTTP aquests no poden fer inspecció de continguts de capa 7 sinó s’adonaran que el tràfic qeu es passa no és legítim, encanvi si fem el túnel sobre HTTPs això no e un problema ja que no es pode inspeccionar les dades que van per sobre de la capa 4 al anar xifrades.
També cal pensar que és habitual que si el mètode CONNECT, que ha de ser suportat pel proxy esta habilitat (cosa rara que passi) segurament estarà restringit a connectar-se al port 80, 8080 i 443 remots, com a molt. Així doncs, si el que volem és fer una connexió SSH el que hem de fer és publicar el servidor SSH per algún d’aquests ports.
Si esteu interessats en aplicar la solució de la connexió SSH sobre proxy HTTP/s ús recomano seguir el manual que hi ha a la pàgina: DAG WIEERS: Tunneling SSH over HTTP(S).

Mar 04

Podcast 2×01: introudcció i descripció detallada del protcol SOCKS5

Reading time: 3 – 4 minutes

Després de moltes hores de feina estudiant el protocol SOCKS he decidit publicar un podcast que expliqui el seu RFC, el podcast pretent fer una introducció des de la part meś conceptual fins endinsar-se en el fluxe de paquets, els camps de les peticions llençades arribant a explicacions de nivell de bit. Amb l’ajuda dels diagrames adjunts a aquest article, l’RFC1928 i l’explicació del podcast després hauriem d’estar capacitats per implementar un client/servidor SOCKS5.

El podcast:

[display_podcast]

Esquemes que ajuden a seguir el podcast

esquema 1: petició d’un client SOCKS5 al servidor

                   +----+----------+----------+
                   |VER | NMETHODS | METHODS  |
                   +----+----------+----------+
                   | 1  |    1     | 1 to 255 |
                   +----+----------+----------+

esquema 2: resposta del servidor SOCKS5 al client

                         +----+--------+
                         |VER | METHOD |
                         +----+--------+
                         | 1  |   1    |
                         +----+--------+

mètodes d’autenticació

  • X’00’ NO AUTHENTICATION REQUIRED
  • X’01’ GSSAPI
  • X’02’ USERNAME/PASSWORD
  • X’03’ to X’7F’ IANA ASSIGNED
  • X’80’ to X’FE’ RESERVED FOR PRIVATE METHODS
  • X’FF’ NO ACCEPTABLE METHODS

esquema 3: el client SOCKS5 envia una comanda al servidor

        +----+-----+-------+------+----------+----------+
        |VER | CMD |  RSV  | ATYP | DST.ADDR | DST.PORT |
        +----+-----+-------+------+----------+----------+
        | 1  |  1  | X'00' |  1   | Variable |    2     |
        +----+-----+-------+------+----------+----------+

camp: ATYP -> address type

  • IP V4 address: X’01’
  • DOMAINNAME: X’03’
  • IP V6 address: X’04’

esquema 4: resposta del servidor SOCKS5 a la comanda del client

        +----+-----+-------+------+----------+----------+
        |VER | REP |  RSV  | ATYP | BND.ADDR | BND.PORT |
        +----+-----+-------+------+----------+----------+
        | 1  |  1  | X'00' |  1   | Variable |    2     |
        +----+-----+-------+------+----------+----------+

camp: REP -> reply

  • X’00’ succeeded
  • X’01’ general SOCKS server failure
  • X’02’ connection not allowed by ruleset
  • X’03’ Network unreachable
  • X’04’ Host unreachable
  • X’05’ Connection refused
  • X’06’ TTL expired
  • X’07’ Command not supported
  • X’08’ Address type not supported
  • X’09’ to X’FF’ unassigned

esquema 5: encapsulaments per enviaments de paquets UDP

      +-----+----+-----+------------------------+------+
      | ... | IP | UDP | SOCKS5 UDP ASSOCIATION | DATA |
      +-----+----+-----+------------------------+------+

esquema 6: camps de l’encapsulament: UDP ASSOCIATION

      +----+------+------+----------+----------+----------+
      |RSV | FRAG | ATYP | DST.ADDR | DST.PORT |   DATA   |
      +----+------+------+----------+----------+----------+
      | 2  |  1   |  1   | Variable |    2     | Variable |
      +----+------+------+----------+----------+----------+

Referències d’utilitat

  • Apunts per fer el podcast: fitxer .txt amb la llista de coses que havia de comentar al podcast és una barreja de català, castellà i anglès… però pot servir-vos per entendre el que intento explicar
  • Wikipedia: SOCKS
  • RFC’s:
    • RFC1928: SOCKS Protocol v5
    • RFC1929: Username/Password Authentication for SOCKS V5
    • RFC1961: GSS-API Authentication Method for SOCKS V5

Mar 01

Les últimes setmanes en fotografies

Reading time: 8 – 12 minutes

Com sembla que és una tònica en la meva vida tot corre molt, tot va molt ràpid i sempre hem passen mil i una coses. Qualsevol diria que normalment treballo des de casa, potser és gràcies a internet que hem permet mourem molt i aprofitar al màxim les sortides. Així doncs, per posar-me al dia he decidit re-editar un post que vaig fer l’any 2007: Fotografies dels últims dos dies. En aquest cas potser parlem de més de dues setmanes però la idea és la mateixa: buidar la targeta del mòbil i anotar coses curioses o no tan curioses al blog.

Des del 24 de gener continuo sense el meu portàtil, o sigui, que ja porto més d’un mes de patiments i esperes. De fet, gràcies a uns companys de LanA2 vaig poder-lo disfrutar garibé una setmana només netejant-lo ben net, però finalment va tornar a morir amb el mateix problema que el primer dia:

Malgrat alguna gent ha tingut la sort de que Dell li ha reparat el problema gratuitament, a d’altres com ara jo no hem tingut tanta sort. Així doncs, per eBay he demanat una placa base nova i encara estic a l’espera de rebre-la. Així podré recuperar el Dell m1330 que tan bon rendiment m’ha donat aquests quasi 3 anys.

Per altre banda, he demanat un Dell Studio 13 que fa més d’1mes que espero que Dell es digni a entregar-me, de fet, avui havia de rebre’l però segons l’estat de la comanda això no serà fins la setmana que ve, cosa que ja hem costa de creure quan han incomplert més de 3 vegades la data d’entrega.

Dell Studio XPS13

A nivell tècnic podriem dir que és l’evolució del m1330. Amb 8GB de RAM, 500GB d’HD i algunes millores en el lector de targetes flash a més d’una gràfica més potent, etc. Però el que realment m’ha fet comprar-ne un de nou no és tan el hardware sinó una garantia de 3 anys del dia després perquè no torni a estar com ara.
Canviant de tema, fa unes setmanes vaig ser al Mobile World Congress (MWC’10) de Barcelona, on vaig aprofitar per retrobar-me amb molts amics, no només durant la fira sinó durant tot el dia. Fins hi tot vaig retrobar-me amb el Fernando que després d’uns anys a Dublin a decidit establir-se a Barcelona. Pel que fa a la fira si no hi heu pogut anar, més enllà de mirar-vos mil fotografies i videos dels mòbils i d’altres cosetes que hi van presentar ús recomano llegir: 20 key trends at Mobile World Congress 2010 (1-10, 11-20).

Aquest any l’entrada va ser gentilesa de Google i més concretament de l’Ernest, que no només ens va aconseguir aquest passe als amiguetes sinó també una entrada a la conferència de desenvolupadors d’Android que es feia a la fira. La sorpresa que ens tenien preparats l’Ernest i la gent de Google és el regal d’un Nexus One al final de la xerrada.

Google Nexus One

Sobre el telèfon comentar que és un Android i com a tal tampoc es diferència tan del HTC Hero que ja tenia, això si quan sortim del sistema operatiu per mirar-nos el telèfon és impressionant el ràpid que arriba a funcionar la CPU d’1GHz i els més de 500MB de RAM. Tot el que feia amb la Hero ara mateix vola amb el Nexus One i quan dic vola vull dir que vola, estic impressionat. Per cert, el meu més gran descobriment dels últims dies a nivell d’aplicacions és una aplicació que es diu WebSharing i que permet compartir tot el mèdia que tinc al meu telèfon via Wi-Fi a través d’una interficie web senzillíssima d’usar i molt potent.

Aquesta setmana passada també ha estat molt especial perquè movilpoint ha venut la seva primera unitat de la nova gama de productes. Després de molts mesos de feina s’ha reorientat totalment la companyia i de forma oficiosa ja puc informar que els nous productes de l’empresa seran totalment hardware, o sigui, que ja no farem software. Són productes totalment ecològics, molt econòmics i fets a mida de cada client a través d’una configuració via web. La gama de producte esta totalment orientada a fires i events, espero poder-vos presentar la nova web ben aviat.

Mentretant podeu veure com estem treballant amb els nous punts d’informació:

i també donar un cop d’ull a la primera unitat instalada a casa d’un client:

Finalment aquest cap de setmana he estat a la DrupalCamp 2010 que es feia al Citilab de Cornellà; després de fer campana al phpWorkShop d’aquest any he passat a coneixer una mica més a fons a la gent i la tecnologia de Drupal. En general he sortit amb molt bon gust de boca de tot plegat, unes xerrades amb un bon nivell tècnic, una organització molt ben portada i una col·lecció de geeks més gran i fidel del que m’imaginava, això si, molt de Mac suelto 😉

Parlant de temes tècnics potser el que més m’ha agradat és SCRUM, que com cap metodologia de projectes és perfecte però si que aporta certs elements d’XP (eXtreme Programming) que sempre he trobat molt interessants. Potser la decepció més gran Open Atrium, no sé perquè m’esperava alguna cosa molt més potent. Per cert, alguna gent com en @quimet i en @linobertrand m’han preguntat què montava jo encomptes d’Open Atrium i això ho vaig respondre a un podcast que vaig fer el maig del 2008: Podcast 1×07: gestió de projectes. Per altre banda, des de llavors també he treballat amb Redmine i el recomano moltíssim, ja que esta molt ben integrat i malgrat esta fet amb RubyOnRails del que no en sé res de res, he de reconeixer que és una solució molt ben pensada i ben feta.

Abans d’acabar algunes fotos de la DrupalCamp 2010:

Dec 28

Introducció a RestMS

Reading time: 2 – 4 minutes

RestMS schemaXMPP és un protocol de missatgeria no només orientat a mantenir converses entre usuaris sinó també a ser usat com a sistema RPC entre diferents aplicacions. Malgrat això res és perfecte i AMQP més orientat a la segona funció que no pas a la primera es perfila com estàndard  corporatiu molt més potent i eficient que XMPP en diversos aspectes. Però AMQP peca per ser força inaccessible degut a que no és trivial d’entendre i usar.

En tot aquest món de la missatgeria entre aplicacions hi ha un altre protocol no tan conegut però que preten tenir el millor d’XMPP i d’AMQP: RestMS. De fet, RestMS és realment una simplifiació d’AMQP que usa com a sistema de transport REST.

Es tracta d’un estàndard obert, amb una implementació Open Source força sòlida. Aquest estàndard ens aporta:

  • sistema d’enrutat de missatges
  • models de cues
  • fàcil d’extendre la seva semàntica
  • simple, perquè és precís i petit
  • segur, usa els sistemes de seguretat estàndards d’HTTP
  • escalable, perquè usa servidors, caches, proxies, etc. del món HTTP
  • resol la dicotomia ‘polling vs events’ usant long-polling, igual que BOSH
  • en principi no disposa de sistema de presència, tot i que es podria montar fàcilment
  • pot codificar durant el transportar les dades en XML o JSON
  • portable en diferents sistemes operatius
  • ofereix interoperatibilitat entre diferents llenguatges de programació

Per tot plegat RestMS es perfila com una alternativa interessant per alguns entorns, aportant una solució simple i potent en molts aspectes. Tot i que teoria en mà, el trobo força més lent que no pas AMQP. De fet, des de que vaig veure com s’usava un sistema AMQP per fer balanceix de càrrega en aplicacions de video usant GStreamer per fer una prova ‘fast and dirty’ em vaig quedar impresionat.

Nov 27

Cues del postfix i informacions relacionades

Reading time: 3 – 5 minutes

Per defecte les cues que té el postfix són:

  • hold: missatges que no s’intenten entregar mai
  • incoming: cua d’entrada de missatges
  • active: cua en la que es decideix amb quin delivery agent s’itenta entregar un missatge
  • defer/deferred: missatges que no s’han pogut entregar per un error temporal es posen en aquesta cua
  • bounce: on es generen els missatges d’error cap al remitent dels missatges que no s’han pogut entregar
  • corrupt: cua que conté missatges danyats amb els que no es pot fer res

Accions que podem fer amb els missatges d’una cua:

  • Listing messages
  • Deleting messages
  • Holding messages
  • Requeuing messages
  • Displaying messages
  • Flushing messages

Gestió de les cues:

  • Mostra l’estat de totes les cues.
mailq
  • Mostrar els 10 dominis amb més missatges pendents d’enviar, sovint va bé per controlar quan ens han usat per fer un email i hi ha molts correus enganxats per enviar.
qshape -s deferred|head -n 10
  • Borrar un missatge de les cues.
postsuper -d ID_MSG
  • Borrar tots els missatges de les cues.
postsuper -d ALL
  • Script per borrar missatges de les cues segons origen o destí:
#!/usr/bin/perl -w
#
# pfdel - deletes message containing specified address from
# Postfix queue. Matches either sender or recipient address.
#
# Usage: pfdel 
#                                                                                         

use strict;

# Change these paths if necessary.
my $LISTQ = "/usr/sbin/postqueue -p";
my $POSTSUPER = "/usr/sbin/postsuper";

my $email_addr = "";
my $qid = "";
my $euid = $>;      

if ( @ARGV !=  1 ) {
die "Usage: pfdel \n";
} else {
$email_addr = $ARGV[0];
}                                    

if ( $euid != 0 ) {
die "You must be root to delete queue files.\n";
}                                               

open(QUEUE, "$LISTQ |") ||
die "Can't get pipe to $LISTQ: $!\n";

my $entry = ;    # skip single header line
$/ = "";                # Rest of queue entries print on
# multiple lines.
while ( $entry =  ) {
if ( $entry =~ / $email_addr$/m ) {
($qid) = split(/\s+/, $entry, 2);
$qid =~ s/[\*\!]//;
next unless ($qid);

#
# Execute postsuper -d with the queue id.
# postsuper provides feedback when it deletes
# messages. Let its output go through.
#
if ( system($POSTSUPER, "-d", $qid) != 0 ) {
# If postsuper has a problem, bail.
die "Error executing $POSTSUPER: error " .
"code " .  ($?/256) . "\n";
}
}
}
close(QUEUE);

if (! $qid ) {
die "No messages with the address <$email_addr> " .
"found in queue.\n";
}

exit 0;
  • Borrar missatges segons email origen o destí.
/root/bin/pfdel email
  • Hold a message / Retenir missatges, no intentar servir-los. Posar-los a una cua congelats.
postsuper -d ID_MSG
  • Hold all messages
postsuper -d ALL
  • Moure un missatge de la cua ‘hold’ a la cua ‘active’.
postsuper -H ID_MSG
  • Moure tots els missatges de la cua ‘hold’ a la cua ‘active’.
postsuper -H ALL
  • Re-encuar missatges, per exemple si el postfix tenia un erro de configuració després de corregir-los podem re-encuar els missatges perquè es corregeixin els possibles errors de classificació que hagin patit. Per exemple, canvi de ‘delivery agent’.
postsuper -r ID_MSG
o
postsuper -r ALL
  • Veure el contingut d’un missatge que esta a la cua:
postcat -q ID_MSG
  • Per forçar el re-enviament de missatges a la cua.
postqueue -s
o
postfix flush
  • Per forçar l’enviament de missatges a la cua per un domini.
postqueue -s domini.com

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.

Jul 03

llibre: “La economía Long Tail”

Reading time: 2 – 4 minutes

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:

long tail graph

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.

Jun 10

NAT traversal: Com funciona ICE?

Reading time: 5 – 8 minutes

Per tal d’entendre com funciona ICE el millor és explicar-lo conjuntament amb un altre protocol; ja que com es va comentar a la introducció del NAT traversal el protol ICE usa una combinació del protocol TURN i STUN en funció del cas, això és molt senzill d’entendre si parlem d’un cas pràctic d’ús. O sigui, quan s’intenta que per exmple, SIP travessi un firewall/gateway/router per fer arribar una trucada a un telefon IP.

Què són els candidats?

El Caller envia un missatge de SIP INVITE amb informació SDP que descriu per quina IP i per quins PORTS l’aplicació pot rebre audio i/o video. Aquestes adreces i ports es coneixen com candidates. Aquests candidates s’obtenen del servidor ICE (sovint es troba dins el firewall/router/gateway).

Podriem descriure un candidate com una IP i un port a través dels quals un peer pot rebre dades d’un altre peer. Hi ha tres tipus de candidates:

  • Local candidate: IP local del client.
  • Reflexive or STUN candidates: una adreça IP pública del servidor NAT.
  • Relay o TURN candidate: una adreça o un relay server que ha estat reservat pel client.

El tràfic sempre es podrà enviar amb èxit a través dels relay candidates, a menys que un firewall bloquegi l’enllaç, aleshores no hi ha tècnica possible de NAT traversal a aplicar. El problema d’usar relay candidates és que requereix usar recursos d’un servidor, això fa que el tràfic que arriba al peer tingui retards, perdues i problemes de jitter.

Procés d’establiment d’una trucada SIP via ICE

1. Caller aconsegueix els seus candidates

En el següent gràfic es pot veure com el Caller determinada els reflexive i relay candidates per una connexió. El client envia una petició d’ALLOCATE al servidor, llavors el servidor localitza un parell IP/port (el relay candidate). Aquesta informació s’envia altre cop al Caller (reflexive candidate), aquest missatge conté la IP pública que usarà el Caller quan emeti un missatge a internet, sovint això és la IP a través de la qual s’aplicarà el NAT.

stun_turn_candidates

2. Caller envia un SIP INVINTE

El Caller construeix un missatge SIP INVITE usant la informació dels candidates que ha obtingut del seu servidor ICE, després l’envia al seu destí.

3. Callee aconsegueix els candidates

Quan es rep el missatge SIP INVITE, el Callee aconsegueix els candidates de la mateixa manera que ho ha fet el Caller en el punt (1).

4. El Callee envia una resposta 1xx

Seguint amb el protocol SIP, el Callee ha de generar un missatge de resposta al SIP INVITE, per exemple, un SIP 183 (Session Progress). Quan es construeixi aquest missatge dins de l’informació SDP el Callee també hi encapsularà els seus candidates. Fins que aquest missatge no s’hagi rebut i confirmat per part del Caller (200 OK) no es considerarà exitosa la negociació.

5. ICE connectivity checks

Arribats en aquest punt tan el Caller com el Calle saben mutuament els candidates que tenen cadascún i és el moment d’usar el que s’anomena ICE connectivity checks. Això es fa enviant un missatge STUN des del local candidate cap al remote candidate, això es pot fer per tants candidates com hi hagin des del que té més prioritat fins al que en té menys. Això ho faran ambdós costats de l’enllaç si és que tots dos es troven darrera un gateway amb ICE. Quan s’hagi determinat quin dels candidates és el millor per establir cada un dels canals llavors s’escollirà aquest candidate per començar a enviar i rebre media a través seu.

A continuació es poden veure tres exemples de com es fan aquestes proves dels candidates. El primer esquema seria el cas en que ambdós hosts són enrutables directament perquè, per exmple, estan a la mateixa LAN. El segon esquema s’aconseguiria l’enllaç via la metologia STUN i en el tercer via la metodologia TURN.

ICE_connection_check

6. Callee envia SIP 180 (ringing)

En aquest punt el Callee envia el missatge SIP 180 (ringing) al Caller per informar-lo de que el teléfon del Callee esta sonant. Al haver negociat previament el canal de dades a través d’ICE quan el Callee despengi el teléfon ja podrà parlar sense retards, si això es negocies després hi hauria un efecte de retard desagradable pels peers.

7. Accepta la trucada i parlen

Així doncs, quan el Callee despengi s’enviarà un missatge 200 OK i via RTP (per exemple) i usant els canals negociats via ICE el fluxe de dades multimedia (en aquest cas audio) començarà travessant de forma transparent els dos gateways que donen accés a internet als dos peers.

Unes notes per aclarir el tema

En aquest exemple es preten demostrar que podem establir un enllaç RTP a través de dos peers que es troben darrera de NAT gràcies al protocol ICE. Com a protocol per controlar la sessió RTP s’usa SIP, això fa que ambdós peers necessitin una redirecció DNAT al seu gateway cap als ports TCP/UPD 5060. En cas de voler evitar això el que s’hauria d’usar és un altre protocol de senyalització diferent de SIP. Per exemple, si no volem/podem redirigir cap port al gateway es podria usar XMPP.

Glosari

  • Caller: qui fa la trucada
  • Calee: qui rep la trucada
  • SDP: Session Description Protocol
  • SIP: Session Initiation Protocol
  • Peer: un extrem de la connexió

Referències