💾 Archived View for texto-plano.xyz › peron › articulos › chaosnet.gmi captured on 2023-01-29 at 03:46:06. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2022-03-01)

-=-=-=-=-=-=-

La Red del Caos

Hoy, el mundo pertenece al protocolo TCP/IP. Estos dos protocolos - junto al UDP - gobiernan la mayoría de las comunicaciones remotas entre sistemas de cómputo. Pero pienso que es maravilloso poder encontrar, aún ocultos entre las alcantarillas de la Internet, secciones de otras cañerías anteriores, casi extintas, con un nombre evocativo. ¿Qué era la Red del Caos? ¿Y porqué está metida en el asfalto telemático, como esos viejos rieles vestigiales del tranvía porteño?

Usemos el comando dig y interroguemos al DNS sobre texto-plano.xyz. Nos responderá crípticamente algo como:

$ dig texto-plano.xyz
; <<>> dig 9.10.8-P1 <<>> texto-plano.xyz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54264
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;texto-plano.xyz.		IN	A

;; ANSWER SECTION:
texto-plano.xyz.	300	IN	A	207.246.69.54

;; Query time: 3 msec
;; SERVER: 108.61.10.10#53(108.61.10.10)
;; WHEN: Sat Jan 15 12:05:50 UTC 2022
;; MSG SIZE  rcvd: 60

Como vemos, la devolución nos presenta una sección que decribe la "pregunta" que le hicimos (¿cuál es la dirección IP de texto-plano.xyz?) y una sección a continuación que nos describe la respuesta que nos da dig. En la sección de respuesta, vemos que encontró un único registro con lo que parecen ser cinco campos. El tipo de registro se indica por la A en el cuarto campo desde la izquierda, este es el registro de la "dirección". A la derecha de la A, en el quinto campo, se puede ver la dirección IP de texto-plano, que es 108.61.10.10. El valor 300 en el segundo campo especifica cuanto tiempo puede ser cacheado este registro en particular (en segundos).

¿Qué nos dice el campo IN? Por un tiempo bastante largo, pensé que el campo IN funcionaba como una preposición, y que cada registro DNS decía algo como "exto-plano.xyz está en A y tiene una IP de 108.61.10.10". Resulta que el IN realmente significa "Internet". La parte de IN en un registro DNS nos especifica la Clase del registro.

¿Porqué entonces el registro de DNS tendría una clase distinta que la "internet"? ¿Qué otra cosa podría haber? ¿Como iba a buscar un huésped que no estuviese hospedado en la internet? Parecería obvio que el único valor almacenado en el registro tendría que ser IN y que hay otro. De hecho, cuando le intentamos interrogar por la dirección de texto-plano.xyz mientras que le especificamos una clase distinta a IN, el servidor DNS probablmente se queje. Por ejemplo, cuando intentamos preguntar la IP de texto-plano pidiendole una clase HS, el nombre del servidor en 8.8.8.8 (el DNS público de Góogle) nos devuelve una REFUSED:

$ dig -c HS texto-plano.xyz

; <<>> dig 9.10.8-P1 <<>> -c HS texto-plano.xyz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 53954
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;texto-plano.xyz.		HS	A

;; Query time: 0 msec
;; SERVER: 108.61.10.10#53(108.61.10.10)
;; WHEN: Sat Jan 15 12:15:22 UTC 2022
;; MSG SIZE  rcvd: 44

De modo tal que otras clases distintas a IN no son bastante soportadas. Pero existen. Además de IN, los registros del DNS pueden tener clase HS (como vimos) o la clase CH. La clase HS está reservada para el uso por un sistema llamado Hesiod, que almacena y reenvia datos textuales simples usando el sistema DNS. Se lo usa típicamente en ambientes locales como un reemplazo para un stack LDAP. La clase CH en cambio se reservaba para algo llamado "La red del Caos".

La sala de máquinas del MIT

ChaosNET fue desarrollada en la década de 1970 por los investigadores del Laboratorio de Inteligencia Artificial del MIT. Fue creada como parte de un proyecto destinado a diseñar y construir una máquina capaz de correr el lenguaje de programación LISP de una manera más eficiente que en un mainframe de propósito general.

LISP era la creación del profesor John McCarthy, precursor estadounidense del campo de la inteligencia artificial. Lo describió por vez primera en un paper de 1960, y para 1962 ya existían un intérprete y un compilador. El novedoso lenguaje introducía muchísimas caracterísicas que hoy consideraríamos estándares en programación. Fue el primer lenguaje en contar con recolector de basura, un REPL, y primero en dar soporte al tecleo dinámico. Como resultado, fue muy bien recibido por los investigadores del campo de la inteligencia artificial, quienes - por nombrar un ejemplo - lo usaron definir la famosa demostración SHRDLU, en la cual podía controlarse un robot computarizado que manipulaba bloques de juguete siguiendo acciones mediante órdenes dictadas en lenguaje natural. Todo un logro de finales de los 60s.

LISP tendía a ser lento y esto era un problema. Las operaciones simples solían tardar el doble de tiempo en ejecutarse ya que las variables de LISP se sometían también a revosión de tipeado tanto al momento de ejecución como en el de compilación. El recolector de basura de LISP es recordado por tardar un segundo entero en el mainframe IBM 7090 del MIT. Estos desempeño maculado no podía dejar de ser muy criticado, ya que los investigadores de IA se concentraban en programar aplicaciones que debían ser capaces de interactuar con sus usuarios en tiempo real. Para finales de la década de 1970, un grupo de investigadores del laboratorio de IA del MIT decidió abocarse a enmendar estos problemas mediante la construcción de máquinas diseñadas específicamente para correr programas LISP. Estas "máquinas LISP" contarían con más memoria y un conjunto de instrucciones más circunspecto, lo que las haría especialmente aptas para funcionar con LISP. La revisión de tipeo se haría en una circuitería dedicada, acelerando el funcionamiento en varios órdenes de magnitud.

A diferencia de la mayoría de los sistemas de cómputo del momento, las máquinas LISP no podrían operar a tiempo compartido, ya que los ambiciosos programas de LISP solían requerir todos los recursos de la computadora. Cada usuario recibiría su propia CPU. En un memo, el Grupo de Máquinas LISP en el MIT describe como esto haría que la programación de LISP fuese mucho más sencilla:

La máquina LISP es una computadora personal. El cómputo personal significa que el procesador y la memoria principal evitan ser multiplexados en tiempo real, sino que cada persona recibe la suya propia. El sistema de computación personal consiste en una lista de reserva de procesadores, cada cual con su propio banco de memoria asociado, y su propio disco para tareas de intercambio. Cuando un usuario abre su sesión remota, recibe la asignación un procesador, que cuenta como uso exclusivo por la duración de la sesión. Cuando cierra la sesión, el procesador vuelve a la lista de reserva, para suplir a la siguiente persona que desee utilizarlo. De esta forma desaparece la competencia entre usuarios por el uso del banco de memoria; las páginas a las que los usuarios refieren con frecuencia permanecen almacenadas en núcleo, de modo tal que la realización de almacenaje de intercambio se reduce considerablemente. Por tanto, la máquina LISP resuelve el problema básico del sistema LISP de tiempo compartido.

La máquina LISP sería una computadora personal en un sentido distinto al que consideramos actualmente. Los usuarios previstos por el Grupo de Máquinas LISP se sentarían en sus oficinas no frente da su propia máquina LISP, sino frente a terminales remotas. Las terminales estarían conectadas a la máquina LISP real, localizada en otra premisa. Cada usuario apropiaría un procesador de la CPU, y ésta se encontraría "alejada, en una sala de máquinas", ya que se preveía que dichos mainframes fuesen ruidosos y voluminosos, y por tanto "no serían bienvenidos como compañeros de oficina". Los procesadores compartirían acceso al sistema de archivado y a dispositivos tales como las impresoras, a través de una red de datos local de alta velocidad "con un control completamente distribuido". Esa red era la Red del Caos (ChaosNET).

ChaosNET consistía tanto en un estándar de hardware como un protocolo (o acuerdo) de software de comunicaciones. El estándar de hardware recuerda al de Ethernet, y de hecho el protocolo de software de Chaosnet podía operar sobre Ethernet de forma eventual. En tanto, el protocolo de software - que escifica tanto la interacción de la capa de red como la capa de transporte - estaba pensado para gobernar siempre una red de tipo LOCAL (a diferencia de TCP). En otro memo publicado por el Laboratorio de Inteligencia Artifical del MIT, David Moon - miembro del Grupo de Máquinas LISP - explica que ChaosNET "no continene provisiones especiales para enlaces de baja velocidad, enlaces ruidosos, ruteos múltiples, ni enlaces de larga distancia con retrasos de tránsito significativos". El foco est6aba puesto en diseñar un protocolo que superara a otros en lo referente a redes pequeñas.

Lo importante para el Caos era la velocidad, ya que ChaosNET residiría entre cada procesador LISP y el sistema de archivado. Los retrasos en la red de datos podían dificultar incluso las operaciones más rudimentarias, tales como ver el contenido de documentos de texto. Para lograr velocidad meteórica de 3 Megabits por segundo, la red del caos incorporaba ciertas mejoras sobre el NCP (el Programa de Control de Red en boga en la ARPAnet). Según Moon, "es importante degollar los cuellos de botella que plagan la ARPAnet, por ejemplo el control de enlace compartido entre múltiples conexiones y del cual se requiere acusar recibo antes de autorizar el envío subsiguiente". El protocolo ChaosNET lotea los acuses de recibo con similitud al TCP actual, y manera de reducir a un tercio el número de paquetes requeridos para transmitir.

ChaosNET podía utilizar también un algoritmo de ruteo relativamente simplón, donde la mayoría de los huéspedes de la red de máquinas LISP se imaginaban enlazados a través de un único cable corto. Moon escribió que el esquema de ruteo de Chaosnet "se predica en asumir una geometría de red simple, donde existen múltiples rutas y que la longitud de estas es lo suficientemente corta. Esto hace innecesario esquemas más sofisticados". La simplicidad del algoritmo hacía que implementarlo fuese trivial. El programa de implementación ocupababa la mitad que el NCP de la Arpanet.

El protocolo Chaosnet contaba con otras idiosincrasias. La dirección de Chaosnet sólo cuenta con 16 bits, la mitad que una dirección IPv4 (lo que tiene sentido ya que Chaosnet sólo estaba pensado para funcionar como una red local). Chaosnet carece de números de puerto. En lugar de ellos, realiza solicitudes de conexión siguiendo un proceso de solicitud de conexión especificando un "nombre de contacto". Este nombre de contacto a menudo consistía unicamente de un nombre de servicio pelado. Por ejemplo, el huésped podía intentar conectarse a otro usando el nombre de contacto "TELNET". En la práctica esto opera de forma mas o menos parecida que TCP, ya que un pedido de servicio a Puerto 80, podría - por lo conocido - recibir un "nombre de contacto" específico como HTTP...

La Clase de DNS para CHAOSNET fue agregada al sistema DNS en el documento RFC 973 de 1986. Reemplazaba a la Clase CSNET, anterior, que estaba definida para dar soporte un protocolo de red de la Red de Datos de Ciencias del Cómputo. No queda claro porqué ChaosNET terminó recibiendo este tratamiento especial dentro del protocolo DNS... existieron otras clases de que podrían haber sido agregados pero nunca lo fueron. Por ejemplo, Paul Mockapetris, principal arquitectosdel DNS, escribió que originalmente imaginó incluir una clase para el protocolo de red de datos de Xerox. Ese, muy usado en PARC, jamás se incluyó. Puede que se haya agregado a Chaosnet simplemente porque los años formativos de la ARPAnet se llevaron a cambio en la compañía de software BBN (de Bolt, Beranek y Newman) en Cambridge, Massachussetts, cuyos ingenieros eran "insiders" del MIT, y primigenios en el desarrollo del TENEX, que aún usaban con devoción. Se dice que este grupo relativamente pequeño - pero muy influyente en el desarrollo de las redes de datos - hacían uso de la Red del Caos y su velocidad del rayo.

Pero el uso de Chaosnet se fue apagando conforme las máquinas LISP fueron desconectándose. Si bien a principios de los 80s las máquinas LISP eran equipos viables comercialmente - las vendían en EE.UU. compañías formadas por ex-MITs tales como Symbolics y LISP Machines Inc - lo cierto es que terminaron desplazadas por microcomputadoras de fabricación masiva y más baratas capaces de correr LISP de forma relativamente veloz sin necesitar carísima circuitería específica. El TCP/IP terminó resolviendo muchos de los problemas del protocolo original de la ARPAnet, a los cuales se había esperado resolvere con la Red del Caos.

Ghost in the Shell

Desafortunadamente no existen gran información sobre la Red del Caos. El RFC 675 - escencialmente el documento borrador del protocolo TCP/IP - fue publicado en 1974. Chaosnet fue desarrollada por primera vez en 1975. TCP/IP terminaría conquistando el mundo, mientras la Red del Caos resultó cincuscripta a una vía muerta.

Pero la vía existe. Existen grupos de retrocómputo encargados de utilizar el protocolo y desarrollar hardware casero capaz de utilizar Chaosnet para lograr los infernales y ya devaluados "tres megas por segundo".

El único remanente realmente visible de la Red del Caos es la clase CH en el protocolo DNS, que lo hace factible de puentear con TCP. Es algo que la encuentro fascinante. La clase CH es un fantasma vestigio de un protocolo de red alternativo para un mundo que ya se decantó por TCP/IP. No puede dejar de ser excitante pensar que al igual que los rieles de los tramways porteños, las últimas trazas de la Red del Caos se encuentran embutidas allí abajo bajo el asfalto de las autopistas de la sociedad digital. La clase CH del DNS es un divertido artefacto de digi-arqueología. Pero también es un recordatorio viviente de que la internet no nació ya formada, que TCP/IP no es la única forma de hacer amar entre sí a las computadoras, y que a "la internet" le sacaron una vuelta en eso de tener el nombre más épico del sistema de comunicación global.