protocol de capa 4: SCTP (Stream Control Transmission Protocol)
Tot navegant per la xarxa fa uns dies que vaig trobar un breu document d’IBM que parlava d’un protocol que fa temps que coneixo però que mai m’havia parat a pensar com funcionava per dintre. Es tracta d’un protocol de la capa de transport que intenta ser una eina molt més precisa i efectiva en alguns problemes que presenten els protocols TCP i UDP al transportar aplicacions d’streaming per sobre seu. Tot i la seva orientació a aplicacions multimèdia es pot usar per moltes altres aplicacions.

Més que fer un resum de les aplicacions que són òptimes corre sobre aquest relativament nou protocol (l’RFC és de l’any 2000) el que jo he trobat molt interessant i que vull explicar una mica aquí són dues funcionalitats que desconeixia completament d’aquest protcol:
1) Multi-homing
En un enllaç podem adreçar el tràfic d’un host a un altre a través de més d’una interficie de xarxa i de més d’una IP. A diferència del protocol TCP les comunicacions no s’estableixen entre un socket que uneix dos hosts, sinó que SCTP ens permet establir connexions que permeten connectar dos hosts a través de més d’una interficie simultaneament. El sorprenent és que el propi protocol de transport, al igual que fa TCP, s’encarrega d’entregar els paquets de forma ordenada a la capa d’aplicació.

2) Multi-streaming
Cada paquet SCTP té una associació d’stremas, o sigui, multiples streams en el seu interior. L’importància d’això esta en que, per exemple, quan estem esperant una retransmissió després d’haver perdut un paquet; això no afecta als altres streams de l’associació d’streams. Aquest és el problema més greu que tenim en TCP, perquè si ens falta el paquet inicial aquest bloc d’informació que ens falta bloqueja la resta d’informació que ja hem rebut. Per això, no és gens òptim treballar en connexions TCP si estem usant aplicacions basades en stream de dades. A part dels problemes de sobrecarrega de tràfic que suposa haver de tenir una capçalera tan pesada com la TCP, en protcol que depenen tan de la latència del canal.

El document també ens parla d’altres característiques molt interessants d’aquest protocol de transport. Per exemple, que per negociar l’obertura d’un enllaç ja no es fa amb una three-way handshake sinó que s’usa un sistema millorat que evita de forma intrínseca els problemes de SYN flood. La resta de característiques no les he vist especialment interessants així que si les voleu coneixer us convido a llegir el document en que m’he inspirat per escriure això: Better networking with SCTP (local).
error booting gentoo linux: populating /dev with device nodes…
Des d’ahir a la tarda que li dono voltes a un problema arrancant una gentoo que fa mesos que funcionava sense problemes. La qüestió és que de bones a primeres va començar a donar un problema i no continuava arracant. L’última informació que donava el /sbin/rc era un error a la línia 24 i just abans publicava aquesta informació: populating /dev with device nodes…. L’error era raríssim deia algo així com: /sbin/rc: line 24: cannot redirect standard input from /dev/null gentoo. Aquest línia del fitxer /sbin/rc diu el següent:
linia 23 - einfo " Populating /dev with device nodes..." linia 24 - try tar -jxpf /lib/udev-state/devices.tar.bz2 -C /dev
Finalment la solució era tan senzilla com comentar la línia 24, fàcil… però complicat de trobar. La solució l’he trobat gràcies a una pàgina boníssima sobre com funciona el UDEV: Computer Help for the New and Veteran User for Linux: UDEV Setup. Realment recomano moltíssim la pàgina és boníssima.
Sobre el meu error jo entenc que el problema és que per algún problema d’incosistència del sistema de fitxers s’ha perdut l’inode que apuntava a devices.tar.bz2 que és una còpia dels fitxers de /dev. Llavors els tar de la línia 24 fallava i és clar no es podia descomprimir. Al comentar-lo l’inici segueix perfectament i els pròpi UDEV genera els fitxers de /dev dinàmicament a mesura que es van requerint.
Jordi Labanda
Doncs fa força temps us vaig parlar de Rion Vernons que feia uns dibuixos guapíssims de noies. Doncs bé gràcies a la nova dissenyadora gràfica que tenim a movilpoint he descobert un nou dissenyador.
Aquest em sembla que és català i ha fet dibuixos de força anuncis famosos, com el de Font Vell. La qüestió és que també agradat el seu estil i per tal de no perdre la referència aquí teniu aquest post.
Com funciona un disc dur…
Tot navegant em vaig trobar aquest video que tenia guardat a l’escriptori, així que com que estic fent-hi neteja el penjo perquè el vegi tothom és molt interessant i el que explica la veu en off encara més:
Servidor USB 1.1
Potser el concepte us sona una mica extrany, una altre forma de definir-ho seria: bridge USB RJ45/Ethernet. La idea és ben senzilla, vull poder connectar un cable de xarxa convencional amb un petit dispositiu que tingui 4 sortides USB. Després des del windows hi ha d’haver un driver virtual de HUB USB, perquè virtual? doncs perquè el HUB USB no esta físicament connectat al sistema ROOT USB del PC. Així doncs, el driver ha de simular que el realment hi esta connectat, fent de bridge a través de la xarxa ethernet. Doncs això tan extrany que demano existeix, com sempre als EUA i el seu preu és d’uns ~100. L’única nota negativa que li he troba a part de que només esta disponible a l’altre punta del món és que només és compatible amb USB v1.1, o sigui, 12Mbps com a màxim. Obviament si fos compatible USB v2.0 no podria desenvolupar la potència de 480Mbps que és el que pot donar la v2 de USB, però almenys donaria molt més que els 12Mbps.
Què guanyem amb aquest invent:
- connectar dispositius USB a més de 100m del PC
- connectar un dispositiu USB a més d’un PC a la vegada
- la resta de funcions ja són massa friquis per explicar aquí
Si ens posem a pensar en com funciona el ‘catxarrillo’ no és tan difícil d’implementar. Dins de la caixeta negra hi podriem fer correr un linux embedded i no seria excessivament difícil configurar-lo perquè envies tots els paquets de capa 2 USB per sobre d’IP a través de la xarxa ethernet. La part més pesada de programar seria la del driver windows, osx i/o linux fent la simulació de que el HUB USB esta connectat al ROOT USB com us comentava abans. Però si implementés això de ben segur que hi posaria una giga-ethernet per poder enviar els 480Mbps per sobre dels 1Gbps de la ethernet i així poder connectar-hi qualsevol dispositiu. Malgrat la teoria sempre és molt maca estic segur que alguna cosa faria que hi haguéssin mil problemes, però això fins que no s’intenta mai se sap.
[serie – fotografia 3] postes de sol des de Panamà

Podeu trobar la fotogràfia original a l’album de fotos. Amb 4 MegaPixels de resolució.