oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: Networking

clearOS Enterprise

2010/01/12 2 comentaris

Reading time: 3 – 4 minutes

clearOS logoAbans de marxar de vacances tot parlant amb el Carles vaig descobrir el clearOS i després d’un parell de dies fent-hi proves esporàdiques no volia deixar l’oportunitat d’escriure quatre ratlles sobre el que m’ha semblat.

Es tracta d’una distribució de linux especialment orientada a petites empreses amb pocs servidors, malgrat per algunes mitjanes empreses també crec que estaria ben indicada. Basada en Redhat/CentOS i totalment focalitzada a ser usada via una interficie web força amigable.

Incorpora diverses eines sempre gestionables desde web que permeten fer funcions de servidor de xarxa i/o de gateway de comunicacions. Per exemple:

  • funcions de directori
    • LDAP amb usuaris i passwords integrats per la resta de serveis
    • gestor de certificats de seguretat
  • funcions de xarxa
    • multi-wan
    • VPN, PPTP, IPSec, OpenVPN
    • DMZ i NAT 1-1
    • funcions de firewall
    • servidor DHCP i DNS
    • UPnP
  • funcions de gateway
    • antimalware: antivirus, antiphing i antispyware
    • antispam
    • gestor d’ampla de banda
    • detector d’intrusions
    • filtres de protocols, fins hi tot P2P
    • filtres de continguts
    • web proxy
    • control d’accés
  • funcions de servidor
    • Windows Networking com a PDC
    • serveis de fitxers i impresores
    • flexshares (diverses formes de compartir fitxers: SMB, FTP, Web, etc)
    • groupware i connector d’outlook
    • servidors de correu: POP, IMAP, SMTP, Webmail i recollida de correu
    • filtres de correu: antispam, antimalware, greylisting i quarantena
    • arxivador automàtic de correu
    • gestor de bbdd MySQL
    • servidor web amb PHP

A més al estar orientat a un entorn professional l’empresa que desenvolupa clearOS disposa d’un servei anomenat clearSDN, a través del qual es pot obtenir:

  • Software Updates Priority security and bug updates to the ClearOS software.
  • Content Updates Required updates to Content Filter, Intrusion Protection, Antispam and Antimalware.
  • Monitoring Alarms and reporting for bandwidth, resource and security management.
  • Remote Services Critical services for VPN, DNS and Remote Server Backup.

Fins hi tot tenen uns dispositius anomenats clearBOX que porten el sistema operatiu integrat i ja disposen d’uns quants ports ethernet, ideals per fer de gateway o fins hi tot de switch.

Com no podia ser d’altre forma tot plegat té un bon manual de suport pels usuaris més novells, ja que només amb una mica d’experiència en l’administració de sistemes tot plegat es fa molt intuitiu.

En general m’ha quedat un bon gust de boca pel que fa a l’eina, potser on més he trobat que coixeja el sistema és en detalls de configuració més avançats, per exemple, del servidor d’OpenVPN i cosetes similars. Però per empreses petites i mitjanes com ja deia abans és més que suficient en la majoria de casos.



Introducció a RestMS

2009/12/28 1 comentari

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.

llibre d’XMPP – notes a peu de pàgina

2009/10/17 No hi ha comentaris

Reading time: 1 – 2 minutes

Després de llegir-me el llibre:

He pres les següents notes al moleskine que guardo aquí per poder consultar en el futur:

  • pg.39: IQ or Message
  • RFC 3920: stanza errors list
  • SleekXMPP llibreria python interessant
    • Apendix F: llistat de llibreries XMPP
  • pg.50: Subscription
  • Presence priority: -127 +128
  • XEP 0191: bloquejar JID o dominis
    • Podria ser interessant per bloquejar clients que no paguen
  • XEP 0079: ideal delivery a pantalles, reliable delivery
    • oblidar-nos de problemes si les pantalles estan offline
    • expiration time dels missatges
    • control delivering
  • XEP 0009: JabberRPC
  • XEP 0072: SOAP over XMPP
  • XEP 0060: PubSub
  • XEP 0163: permet que JID sigui un ‘collection node’ que agrupi serveis PubSub això es pot publicar junt amb les capabilities
  • Pg. 132/150: ICE, molt bona explicació
  • Pg. 145/163: VNC over XMPP es pot fer usant socks5 com a proxy segons XEP
  • XEP 0050: remote commands
  • BOSH: 180/198
  • Pg. 189/207: Serverless Messaging
  • Pg. 267/285: DNS SRV

Nagios external commands

2009/10/07 No hi ha comentaris

Reading time: 1 – 2 minutes

Tan de temps usant nagios i mai havia tingut la necessita de recorrer als Nagios External Commands. Escencialment es tracta d’una named-pipe que usa Nagios per rebre comandes via shell.

  • Sintaxis per injectar les comandes. Per suportar aquesta funcionalitat previament cal haver-la habilitat al fitxer de configuració de nagios, això també ho trobareu a l’anterior enllaç.
  • Comandes suportades, la llista és força gran i hi podem trobar coses com ara forçar un check per host o fins hi tot deshabilitar els checks sobre un servei o un host.

A continuació adjunto la comanda que podeu llençar desdel prompt per llençar una ordre al nagios al cap de deu segons. En aquest cas forcem que es verifiquin tots els serveis d’un host.

# des del directori on hi ha la 'named-pipe' sovint anomenada 'nagios.cmd'
now=$(date +%s); next=$(expr $now + 10); echo "[$now] SCHEDULE_FORCED_HOST_SVC_CHECKS;nom_host;$next" > nagios.cmd

Per veure el resultat de la comanda i si aquesta ha estat rebuda pel nagios només cal que mirem el fitxer nagios.log. La sortida del log serà algo així:

data host_server nagios: EXTERNAL COMMAND: SCHEDULE_FORCED_HOST_SVC_CHECKS;nom_host;unix_ts

Glosari de Telepathy

2009/07/21 No hi ha comentaris

Reading time: 3 – 4 minutes

Abans que res una petita introducció a: Què és Telepathy?

Es tracta d’un framework que unifica diferents sistemes de comunicació en temps real. Usa DBUS com a interficie de comunicació entre aplicacions.

Avantatges de Telepathy:

  • Temps real: suporta sistemes IM (un-a-un i grups), video trucades i trucades de veu.
  • Unificat: permet que diferentes aplicacions i de forma simultànea s’aprofitin de les capacitats del sistema i que treballin de forma col·laborativa.
  • Framework: disecciona el sistema de comunicacions en petites parts i les fa tan simples com pot perquè al usar-les contjuntament el procés de comuncació sigui el més senzill possible.

El glosari de termes, en poques paraules el que cal tenir en ment i recordar quan parlem de Telepathy.

  • MUC (multi user chat): o també anomenat chat room, o canal de xat.
  • Mission Control: responsable de la gestió de comptes de missatgeria: creació de connexions i manteniment dels estats de presència dels contactes.
  • Glabbe: és un connection manager de Jabber.
  • Tapioca: és un framework per VoIP i aplicacions IM. Suporta SIP/XMPP.
  • Farsight: idem que el Tapioca, però orientat a videoconferències.
  • Stream Engine: exporta les funcions de Farsight a DBUS. i viceversa.
  • Tubes: és el mecanisme que usa Telepathy per suportar transferència de dades entre aplicacions remotes, o sigui: remote IPC. La idea que hi ha darrera és “si dues persones connectades a un servei de IM poden parlar, perquè dues aplicacions connectades a un IM no poder intercanviar informació”.
  • Stream Tubes: és un mètode de transport usat per Telepathy molt similar al SOCK_STREAM sockets: enviament de paquets ordenat i confiable.
  • IB (in-band): quan els ‘Tubes’ usen el servidor de missatgeria per intercanviar dades. Aquest sistema pot ser molt lent per transportar depèn quin tipus d’informacions, per exemple, sessions VNC.
  • OOB (out of band): els ‘Tubes’ de dades usen diferents camins fora de la xarxa XMPP, per exemple, connexions directes entre peers via UDP o TCP.
  • Empathy: es tracta d’un client d’IM programat usant les llibreries de Telepathy.
  • XEP-0095 Stream Initiation: aquesta especificació defineix una extenció d’XMPP que iniciar fluxes de dades entre dos entitats connectades a la xarxa XMPP. El protocol soporta la possibilitat d’incloure metadades sobre el fluxe de dades a intercanviar.
  • XEP-0065 SOCKS5 bytestreams abstract: es defineix una extenció d’XMPP per establir connexions OOB entre dos peers, la connexió entre els peers pot ser directe o via un proxy SOCKS5, en principi la idea és usar TCP per aquests tipus d’enllaços malgrat també podria funcionar per UDP.
  • XEP-0163 PEP (Personal Eventing Protocol): defineix la semàntica d’un protocol que usant les funcions publish-subscribe d’XMPP dinfon els canvis d’estat i presencia. D’aquesta forma podem fer funcionar l’estat d’una compte com si es tractés d’un servei pubsub; simplificant la possibilitat de sindicar-nos a dades i notificacions associades amb aquella compte. Un exemple, per fer-ho més entendor: podem tenir un servei d’agenda que ens avisa que hem de fer certes coses si és que estem disponibles però si en canvi este ausents no té sentit que ens avisi.
  • XEP-0080 User Location: és una extenció per permet enviar informació sobre la posició geogràfica de l’usuari.

XMPP amb BOSH: usant HTTP com a protocol de transport

2009/07/14 1 comentari

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.

NAT traversal: Com funciona ICE?

2009/06/10 No hi ha comentaris

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


NAT traversal: Com funciona STUN?

2009/05/28 3 comentaris

Reading time: 2 – 3 minutes

El servidor STUN ha de publicar la seva IP (3478TCP/UPD o 5349TLS) a un gateway que tingui una IP interna i una externa (privada i pública). La comuniació comença quan el client que esta a la xarxa enmascarada llença una serie de requests contra la IP pública del servidor STUN. El servidor STUN contestarà al client informant dels parells de ports usats a l’exterior del NAT, amb això el client aprent de quin tipus de NAT disposa i quin és el TTL dels bindings que es fan a l’exterior per re-enviar les seves peticions.

Una aplicació client per tal de saber qui és el seu servidor STUN el que fa és buscar al seu domini DNS la resolució del nom _stun_.domini_exemple.com o _stun._udp.domini_exemple.com pels tipus de registre SRV. Després de saber qui és el seu servidor STUN el que fa l’aplicació és buscar l’adreça pública del servidor STUN. Per tal de descobrir quin haurà de ser l’origen dels seus paquets a internet. Així quan construeixi els paquets amb les dades d’aplicació podrà advertir quina és l’adreça pública del seu servidor STUN.

Arribats a aquest punt sovint en tenim prou com per començar la comunicació amb el destí final del nostre enllaç, ja que aquest l’únic que haurà de fer és contestar els paquets pels mateixos ports que el gateway esta fent binding en aquell moment. Aquí és on el STUN server fa la seva feina mantenint els ports oberts. Un dels problemes amb els que ens podem trobar és que el node destí no pugui atacar aquells ports per alguna restricció del seu firewall o similar. Cosa que complica la possibilitat de fer l’enllaç. Si els dos hosts que volem comunicar estan tots dos darrera del NAT-masquerade la cosa és fa molt difícil i sovint fa falta un proxy entre els dos servidors STUN per tal de que la cosa funcioni, o sigui, que es complica moltíssim.

Diagrama de fluxe del protocol:

Esquema NAT
Click for (+) Zoom

NAT traversal: Introducció

2009/05/27 1 comentari

Reading time: 3 – 5 minutes

Avui en dia és molt usual tenir xarxes darrera de gateways (routers, firewalls, etc) que a través de NAT donen accés a internet als hosts, sovint anomenem masquerading a aquesta funcionalitat que no deixa de ser un subconjunt de funcions del propi NAT. La majoria de problemes associats a l’accés a internet via masquerading estan solucionats. Però quan el problema que tenim és l’invers, o sigui, que volem accedir, via TCP o UDP, a un host  que esta dintre una xarxa amb un gateway que fa NAT la cosa es complica.

De fet, si el que volem és redirigir un port de la IP pública amb la que s’accedeix a internet a un host intern tampoc no té massa misteri, gràcies al DNAT. Però si aquestes redireccions han de ser a més d’un host sovint hem de començar a usar ports no massa estàndards per oferir serveis que hi ha dins la xarxa i que volem publicar a internet. O sigui, que l’únic que podem fer a priori és mapejar estàticament ports de la IP pública cap a certs ports de les IPs privades.

Per tal de poder rebre connexions en un host que esta darrera un gateway que fa NAT hi ha una serie de tècniques més o menys (des)conegudes.

  • TURN (Traversal Using Relay NAT): la idea és tenir un pool d’IPs públiques de forma que les aplicacions que necessitin ser publicades a internet agafin una IP disponible de forma temporal o permanen per publicar aquell servei en aquella IP que mapejarà els seus ports. O sigui, que es basa en una idea similar al DNAT però li afegeix la capacitat de poder usar pools d’IPs de forma dinàmica.
  • STUN (Session Traversal Utilities for NAT): Esta orientat a aplicacions de VoIP, missatgeria, videoconferència, etc. Sovint quan les connexions per les que s’usa STUN són via UDP, malgrat també hi poden haver servidors que STUN que funcionin amb TCP o fins hi tot TCP/TLS.  El protol STUN és un protocol client-servidor molt lleuger.
  • ICE (Interactive Connectivity Establishment): finalment la idea d’ICE és buscar la millor ruta entre dos hosts que volen comunicar-se. Si ambdós estan dintre la mateixa LAN o en LANs diferents però tenen IPs públiques o NATs estàtics (1a1), llavors enruta les connexions i llestos. Però si els hosts estan darrera de NAT que fan enmascarament dinàmic llavors usa combinacions de les tènciques d’STUN i TURN.

Per tal d’entendre millor aquests problemes cal tenir clar els tipus de NAT que existeixen:

  • Full Cone NAT

    • Esquema NAT
    Click for (+) Zoom

  • Port Restricted Cone NAT

    • Esquema NAT
    Click for (+) Zoom

  • Restricted Cone NAT

    • Esquema NAT
    Click for (+) Zoom

  • Symetric NAT

    • Esquema NAT
    Click for (+) Zoom

    En els propers articles desenvoluparé més a fons els protocols citats i referenciaré algunes llibreries que els implementen.

    La major part de la bibliografia l’he extret de la wikipedia, dels estàndards IETF i de les següents fonts:

    • PDF de NAT types de la web: http://www.crfreenet.org/~martin/referaty/stun/naty.pdf (local)

XMPP: introducció

2009/05/01 No hi ha comentaris

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ó: