Ley de Cunningham o De cómo funciona esto

La Ley de Cunningham reza así "La mejor manera de conseguir la respuesta a una pregunta en Internet no es realizando la pregunta, sino escribiendo una respuesta equivocada"

XKCD - Duty Calls

En original "The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer". En francés, que es más molón, dicen "prêcher le faux pour savoir le vrai". Los alemanes son concisos al respecto: "Leck mich am Arsch". En este enlace a Emezeta hay un montón de principios y leyes igualmente relevantes.

Cloudshark, analizador de protocolos en la nube

Acabo de descubrir Cloudshark, un analizador de protocolos online que permite realizar un análisis sobre la marcha de un .pcap al estilo de Wireshark. Ideal por ejemplo para ver una captura desde una tablet tipo iPad/Galaxy etc etc...


Tiene incluso la funcionalidad Follow TCP stream. En este enlace podéis ver un ejemplo de tráfico analizado con Cloudshark: http://www.cloudshark.org/captures/f62e1db77ba0 para empezar a jugar con el asunto.






Como siempre, gracias por venir. Si te gustó el post puedes apuntarte a través del correo electrónico o por medio del feed RSS (más información acerca del RSS). También puedes seguirme a través de mis elementos compartidos de Google Reader y desde Twitter.

Richard Hammning - Códigos de Hamming

El ordenador en el que escribo este post tiene 8 gigabytes de RAM, esto son 68.719.476.736 bits (68.000 millones de unos y ceros). Por fuerza algunos han de fallar antes o después y una única instrucción de máquina errónea puede ocasionar cuelgues, pérdida de datos...

Sin embargo los ordenadores son extremadamente fiables, gracias en gran parte al genial Richard Hamming (11 Febrero 1915 – 7 Enero 1998) entre cuya extensísima lista de contribuciones a la informática destaca la invención de los denominados códigos de Hamming, un mecanismo conocido como SECDED ("single error correction, double error detection")

En efecto, muchas memorias llevan un sistema de detección y corrección de errores de Hamming que minimiza los problemas ocasionados por los fallos de los componentes individuales. Esto se logra mediante redundancia, almacenando 64 bits de datos en 72 bits de memoria física usando un código denominado de distancia 4. Si uno de esos 72 bits es golpeado por un rayo cósmico el sistema detectará y corregirá el error. En el improbable caso de que dos bits del mismo bloque fallen el sistema podrá al menos detectar el error y disparar un sistema de emergencia, por ejemplo bloqueando el ordenador en vez de permitir que los datos se corrompan.

Merece la pena dedicar unos minutos hoy a leer su genial "You and your research" (PDF, inglés, 16 páginas) que ya comentamos aquí hace un año.





Fuente: Wikipedia. Como siempre, gracias por venir. Si te gustó el post puedes apuntarte a través del correo electrónico o por medio del feed RSS (más información acerca del RSS). También puedes seguirme a través de mis elementos compartidos, y a partir de ahora desde Twitter o Friendfeed.

4.3.2.1, el DNS de Google

Es una de las noticias del día: Google va a ofrecer el servicio DNS (la otra, por supuesto, es el follón que se ha armado con el intento de colar un comisariado político -la Sección Segunda, en adelante SS, de la Comisión de Propiedad Intelectual del Ministerio de Cultura- con la excusa de salvaguardar los derechos de autor, muy legítimos por otro lado, que yo soy autor, conste, ¡¡¡Ramoncín!!! ¿¿¿que hay de lo mío??? :)

El DNS es el pegamento de Internet: por simplificar la cosa, los ordenadores, los routers, todo en Internet funciona a base de números (y sobre todo en torno a unos números de 32 bits denominados direcciones IP). Lo que ocurre es que a las personas se nos da mejor recordar una dirección tipo http://www.google.com que una dirección como http://74.125.53.100/. Los ordenadores lo que hacen es consultar, mediante un protocolo denominado Sistema de Dominio de Nombres (Domain Name System, DNS) a qué dirección IP le corresponde una dirección de las que tienen sentido para las personas. Este estupendo comic de Proyecto Autodidacta lo explica perfectamente:


Google, en un inteligentísimo paso, reconoce el papel estratégico de este protocolo y ofrece varios servidores con una serie de direcciones sencillisimas de recordar tales como 4.3.2.1, 8.8.8.8 y 8.8.4.4 contra las que apuntar nuestros sistemas para realizar esta resolución de direcciones. En este enlace vienen instrucciones sobre como configurar diversos sistemas para usar este servicio.

Por supuesto este nuevo servicio de Google no viene a satisfacción de todo el mundo, sobre todo para aquellos que ven en este movimiento una nueva vuelta de tuerca dentro de una estrategia de dominación mundial. Así, por ejemplo, tenemos a David Ulevitch de OpenDNS, al que la noticia evidentemente le ha caído como una patada en el culo inquietado mucho y no ha tardado en manifestar su punto de vista contrario en este interesante post.






Fuente: Google. Ilustración: magnífica web Proyecto Autodidacta. Como siempre, gracias por venir. Si te gustó el post puedes apuntarte a través del correo electrónico o por medio del feed RSS (más información acerca del RSS). También puedes seguirme a través de mis elementos compartidos. En la redacción de este post no se han maltratado ningún servidor DNS.

Comunicaciones vía Meteoritos - Técnicas de Comunicación Extrema I

Presentamos hoy una técnica de comunicaciones curiosa y en general bastante desconocida, las comunicaciones vía meteoritos. Esta asombrosa técnica, denominada en inglés Meteor Burst Communications (MBC) y a veces Meteor Scatter Communications, propaga emisiones de radio aprovechando las estelas ionizadas dejadas por los meteoritos al arder en contacto con la atmósfera, permitiendo el envío de breves mensajes hasta distancias superiores a los 2000 kilómetros.

Las frecuencias así reflejadas están determinadas por la intensidad de la ionización creada por la estela de cada meteorito, a su vez función del tamaño inicial de la partícula, y generalmente están entre los 20 y los 500 MHz. El origen de la técnica hunde sus raíces en las observaciones realizadas por el japonés Hantaro Nagaoka en 1929.

Durante los años 50 y 60 del siglo XX se hizo un uso fundamentalmente militar de este sistema a través de infrastructuras tipo COMET (COmmunication by MEteor Trails) de la OTAN (de 115 a 310 bits por segundo) o AMBCS (Advanced Meteor Burst Communications System), un banco de pruebas financiado con fondos DARPA que, usando antenas direccionales apuntando hacia la dirección a la que la tierra "avanza", incrementaron la técnica hasta los 4 kbit/s

El progresivo uso de las comunicaciones vía satélite hizo que esta técnica haya caído en un olvido relativo, aunque las limitaciones de las comunicaciones vía satélite hacen que en ciertas latitudes se siga usando este sistema. Un ejemplo es el Alaska Air Command MBC system, operativo en los 70 del pasado siglo, aunque se desconoce si en la actualidad es operacional.


Actualmente el sistema es usado por la red SNOTEL para la medición remota de contadores de agua (accesible online) así como por el Alaskan Meteor Burst Communications System (AMBCS) ya antes mencionado para la recolección de datos metereológicos, por algunos radioaficionados e incluso a través de empresas como MeteorComm, que comercializan servicios basados en esta interesante técnica.





Para profundizar, Meteor Burst Communications en la Wikipedia. Un clásico, RAND's Introduction to Distributed Communications Networks por Paul Baran. Como siempre, gracias por venir. Si te gustó el post puedes apuntarte a través del correo electrónico o por medio del feed RSS (más información acerca del RSS). También puedes seguirme a través de mis elementos compartidos.

Generador de Códigos QR Online

Zebra Crossing es una web donde podemos crear rápidamente códigos QR, imágenes similares a códigos de barras bidimensionales que contienen mucha información y que pueden escanearse con la cámara de un móvil y un software como éste. En esta página podemos crear QR-Codes personalizados a través de formularios que facilita la creación de tarjetas de visita (tal como recomienda Lucio Albenga en su reciente post), enlaces a páginas web, SMSs, entradas de calendario, coordenadas GPS o un texto normal y corriente, como éste que os pongo a continuación con el que os animo a practicar todo esto a la vez que aprendéis una valiosa lección en forma de refrán.


Ahora bien, hay que tener mucho ojo con este tipo de códigos ya que, como explican en consumer.es, leerlos no tiene un coste en sí, pero pueden desencadenar acciones tales como activar el envío de mensajes, iniciar llamadas a números de tarificación especial o simplemente solicitar la carga de una página web, con el consiguiente establecimiento de una conexión del móvil a Internet.

Fuente: Zebra Crossing. Una vez más, gracias por venir. Si te gustó el post puedes apuntarte a través del correo electrónico o por medio del feed RSS (más acerca del RSS). También puedes echarle un vistazo a mis elementos compartidos. Y recuerda, Wan Link Sniper no fabrica para otras marcas.

Dibuja automáticamente diagramas de secuencia

El Ornitorrinco Enmascarado me descubre WebSequenceDiagrams, una magnífica herramienta online que permite elaborar diagramas de secuencia UML a partir de una descripción textual muy intuitiva. Estos diagramas muestran la interacción de un conjunto de objetos a través del tiempo proporcionando detalles de la implementación del escenario así como de los mensajes pasados entre los objetos que lo componen, y son ideales para describir el funcionamiento de los protocolos de red. Por ejemplo, esta descripción de una sesión TCP...

Cliente->Servidor: SYN
Servidor->Cliente: SYN/ACK
Cliente->Servidor: ACK
note over Cliente,Servidor: Conectados
Cliente->Servidor: PUSH
Cliente->Servidor: PUSH
Servidor->Cliente: ACK
Cliente->Servidor: FIN
Servidor->Cliente: FIN/ACK
Servidor->Cliente: FIN
Cliente->Servidor: FIN/ACK

... se convierte a través de la aplicación en este diagrama

Los diagramas pueden generarse en distintos estilos, exportarse en formato PDF y además la web proporciona diversos mecanismos para embeber los resultados en nuestras aplicaciones así como APIs en Python, Java y Ruby para integrarlo con nuestros proyectos. También dispone de un foro donde discutir el producto y proponer mejoras. El Ornitorrinco y el Peje verde han estado jugando con el invento y han encontrado interesantes posibilidades que posiblemente los diseñadores del producto no contemplaron:


Actualización: Voy adquiriendo nuevas destrezas con la aplicación. Así, la conocida historia del chamán de Alcudia y la sanación por la vela queda convertida en este diagrama.

Fuente: directamente pirateado de El Ornitorrinco Enmascarado. Si te interesó el post puedes apuntarte a través del correo electrónico o por medio del feed RSS (más acerca del RSS).

Pila IPv6 de tan 11 Kilobytes

Cisco, Atmel y el Instituto Sueco de Ciencias Informáticas (SICS) han liberado uIPv6, la pila de protocolos IPv6 más pequeña del mundo de tan sólo 11 kilobytes de código y 2 kilobytes más de memoria dinámica para sus cálculos y estructuras de datos. La intención es proporcionar direcciones IP de forma masiva a dispositivos tales como termómetros o bombillas.

uIPv6 será incluido como parte de Contiki, un sistema operativo para sistemas embebidos de código abierto. Investigando un poco sobre este sorprendente micro sistema operativo encuentro que ha sido portado con éxito a plataformas tan insospechadas como el Commodore 64 (en la imagen) o el Vic20.

Si alguien se anima a portarlo al Spectrum puede contar conmigo como betatester. Contiki/uIPv6 pueden descargarse de la página oficial de Contiki en el SICS. También podemos obtener una breve descripción técnica de uIPv6 (PDF, Inglés, 32 KB, 2 páginas).

Fuente: Slashdot. Gracias por venir. Si te interesó el post puedes apuntarte a través del correo electrónico o por medio del feed RSS (más acerca del RSS).

Fast TCP, acelerando Internet

TCP es uno de los protocolos fundamentales en Internet. Creado en 1973 por Cerf y Kahn, TCP da soporte a muchas de las aplicaciones más populares de Internet como la navegación web, el correo electrónico y la transferencia de ficheros. Algunas estimaciones indican que el 95% de los paquetes que circulan por Internet son paquetes TCP. El protocolo TCP, desarrollado y complejo, ha mantenido sus operaciones básicas sin cambios desde la publicación del RFC 793 en 1981.

La implementación más extendida de este protocolo a día de hoy es TCP Reno. Durante la transmisión de datos, cuando un servidor recibe un paquete TCP responde al emisor mandándole una confirmación (ACK). Cuando el emisor recibe la confirmación manda otro paquete, y así en adelante. En un momento dado, un número indeterminado de paquetes pueden encontrarse en tránsito.

TCP hace uso de un algoritmo denominado AIMD que incrementa lentamente la velocidad cuando los envíos y sus confirmaciones van llegando bien, pero que cuando las cosas se tuercen reacciona frenando bruscamente la tasa de transferencia en un 50% (algo similar a cambiar de quinta a segunda marcha) y sin dar la opción de frenar de forma gradual. Con ficheros pequeños (correos, páginas web) apenas se nota, pero cuando se trata de grandes transferencias de ficheros este comportamiento es muy poco eficiente. Por ejemplo, una reducción del 30% en una línea de 10 megas puede representar la diferencia entre recibir vídeo en alta definición y recibirlo en resoluciones convencionales. Y un frenazo del 50% en una línea OC-3 significa pasar de 155 a 77.5 Mbps.

En 1994 Brakmo, O'Malley y Peterson propusieron otra implementación TCP denominada TCP Vegas que consigue mejoras de rendimiento de entre un 40% y un 70% y reduce las pérdidas hasta el 50% en comparación con TCP Reno, TCP Vegas es compatible con cualquier implementación válida de TCP, y los cambios quedan confinados al lado emisor.

Al igual TCP Vegas, Fast TCP es un algoritmo de control de congestión para TCP, diseñado por investigadores del Cal Tech, compatible con los algoritmos TCP ya existentes, requiriendo sólo modificaciones en el ordenador que envía los datos. El papel del control de la congestión es el de modular la tasa de transferencia de datos en función de la capacidad de la red. Fast TCP intenta superar los puntos flacos del algoritmo AIMD midiendo los tiempos entre el envío y la recepción de las confirmaciones (ACKs), y siguiendo la pista a los paquetes perdidos.

FastSoft ha desarrollado un dispositivo, el E-Series Accelerator, que usa el algoritmo Fast TCP para determinar la forma más rápida de enviar los paquetes sin inundar las redes, restringiendo la pérdida de paquetes a niveles aceptables, y haciendo las transferencias más estables.Esta tecnología sitúa al E-Series Accelerator de FastSoft tanto en la categoría de aceleradores de Internet como en la de elementos de distribución de contenidos por red.

Fuente: GigaOM. Apúntate vía RSS (¿cómo?).

Cabeceras IP, TCP, UDP e ICMP

Matt Baxter ha hecho unos estupendos diagramas mostrando la estructura de las cabeceras IP, TCP, UDP e ICMP, tanto en formato PDF como en formato PNG. Muy útil.

Fuente Matt Baxter vía Hotware. Si te interesó este post puedes suscribirte a través del Feed RSS. (¿Qué es RSS?).

¿Qué diferencia hay entre un router, un hub y un switch?

Se trata de dispositivos de red que trabajan con información distinta para tomar sus decisiones: Un hub (concentrador) conecta dispositivos a un mismo nivel físico (compartición de medio). Cuando el número de dispositivos conectados a un único medio crece, estos compiten por acceder al nivel físico y se producen "colisiones". Una solución consiste en usar switches (conmutadores), que usan información adicional o "de enlace" para separar los dispositivos en distintos "dominios de colisión" separando los medios físicos. Algunos paquetes con muchos destinatarios (paquetes "broadcast") no son controlables a través de dominios de colisión. Los routers (enrutadores) usan información adicional ("de red") para separar nuevamente las redes en dominios de difusión.

Además, los routers suelen conectar redes con tecnologías distintas: el típico router casero para salir a internet tiene una interfaz ADSL que conecta con el proveedor del servicio, uno o varios puertos ethernet del lado del cliente (frecuentemente organizados como un switch) y un acceso inalámbrico o Wifi para conectarnos con el portátil o la PDA desde dónde nos pille. El router recoge los paquetes y los traduce de un medio a otro (quitando y poniendo cabeceras, ajustando velocidades, etc...). Cada vez más incorporan un pequeño firewall que usa información de las aplicaciones para filtrar los paquetes no deseados.

Cada dispositivo usa fundamentalmente la información de una capa para realizar su función, y sólo necesita implementar algunas de capas del protocolo:


La aplicación [1] en el Host A (cliente) quiere conectarse con un servicio alojado en el Host B [6] (servidor). La información baja por la pila de protocolos hasta que la tarjeta de red del Host la pone en la red [2]. Ahí es recibida y amplificada primero por un hub [3], básicamente un repetidor que trabaja "a nivel físico" amplificando señales (los pulsos eléctricos que representan los bits). Luego los paquetes son recibidos por un switch [4] que usa la información contenida "a nivel de enlace" en las cabeceras de los paquetes (por ejemplo direcciones MAC) para separar el tráfico. A continuación la información es recibida por un un router [5] que trabaja "a nivel de red", de forma que los paquetes suben hasta la capa de red de la pila de protocolos del router para extraer las direcciones de red (típicamente direcciones IP) y se decide cómo se deben distribuir (por qué interfaz de red se debe sacar el paquete).

¿Encontró este post útil? Considere suscribirse a nuestro Feed/RSS. (¿Qué es RSS?).