Figura 4.8. Ejemplo de programa en tarjeta perforada pág

Proyecto Fin de Carrera

Ahora cada miembro tenía un rol específico, Crowther trabajaba en la comunicación entre imps programando y diseñando software, Walden en las tareas de comunicación del imp con el servidor, mientras Cosell se ocupaba en herramientas de desarrollo y depuración, y Ornstein dirigía la implementación del hardware. Debía realizar una implementación para el "Honeywell 516" que lo convirtiera en un dispositivo de entrada/salida de alta velocidad, la idea era elaborar un conjunto bien detallado de modificaciones de tal manera que Honeywell pudiera fabricar los imps. En ese punto, tenían que decidir qué operaciones serían desempeñadas por el software y cuales por el hardware, las tareas simples las desarrollaría este último, pero había que considerar que una vez construido sería difícilmente modificable, por lo que como norma preferían las soluciones programables, si algo lo podía realizar el software suficientemente rápido, así sería. Se diseñó una función de reinicio por si se producía un fallo en la alimentación, de tal forma que la máquina paraba y se reiniciaba automáticamente una vez volviera la electricidad, debido a que en aquella época se trabajaba con las llamadas memorias core (densa matriz de finos cables de cobre y anillos magnéticos férricos o cores, cada uno del tamaño de una semilla, también conocida como memoria principal) el dispositivo arrancaría al principio del programa gracias a su naturaleza no volátil. En caso de que algún imp cayera o se rompiera, en un principio se diseñó de tal forma que habría que cargar de nuevo el programa (cintas de papel perforado por aquel entonces) sin embargo la BBN inventaría un esquema mucho más ingenioso mediante el cual el imp vecino recargaría el programa reparándolo sin necesidad de que alguien tuviera que hacerlo, la robustez era la consigna en la realización del diseño.

Fig.4.8. Ejemplo de programa en tarjeta perforada.

El equipo de trabajo comenzó a escribir código para el software. Escribir las instrucciones que debía llevar a cabo el IMP, requería pensar en un gran número de pasos en lenguaje de alto nivel, donde las órdenes son cortas y precisas, del tipo: "ve a la puerta, gira a la derecha, anda diez pasos, mira a tu izquierda" (aún recuerdo mi primera clase de programación, donde tuvimos que explicar cómo hacer una lasaña...) y más aún en su equivalente en el lenguaje de ensamble (lenguaje de programación de

Proyecto Fin de Carrera

bajo nivel para los computadores, micro-controladores y otros circuitos integrados programables. Implementa una representación simbólica de los códigos de máquina binarios y otras constantes necesarias para programar) que sería algo así como "encuentra tu pie derecho, encuentra tu pie izquierdo, sitúa tu pie derecho delante del izquierdo. Ahora sitúa el izquierdo delante del derecho. Repite esto diez veces. Para. Gira noventa grados a tu derecha...". Programar en este lenguaje obligaba a volverse un tanto maniático, a veces incluso se olvidaban la meta que perseguían en el propio camino. El código se escribía en un primitivo editor para PDP-1 desde el Model 33 Teletype. Después se creaba el código para el propio PDP-1 y era transferido a cinta de papel para el ordenador Honeywell, donde era convertido a lenguaje de máquina Honeywell, tarea que realizaba un programa conocido como ensamblador, que convertía el código en unos y ceros. El código ensamblado volvía a perforarse en la cinta de papel. El resultado tras catorce horas podía ser una cinta de casi media milla. A medida que se avanzaba, se hacía patente que la red sería un híbrido con respecto a las ideas originarias de Baran y Davies. El esquema de enrutamiento adaptativo fue cosecha propia de los chicos de la BBN, aunque era similar a la idea básica de Baran, se diferenciaba notablemente en el nivel de redundancia o lo que es lo mismo, el número de enlaces a cada nodo. En el esquema de la BBN los nodos poseían dos conexiones, rara vez una o tres, Baran afirmaba que una red con multitud de enlaces redundantes podría ser construida a base de partes de muy bajo presupuesto. El nivel de baja redundancia se acercaba más al modelo de Davies. La aproximación en la que se basaba Heart era fabricar nodos lo más robustos y fiables posibles. También descubrieron que la velocidad de funcionamiento sería mayor de lo que imaginaban, mientras escribían el kernel o núcleo del software, descubrieron algunos comandos que serían necesarios para introducir los paquetes en el IMP, calcular donde enviarlos y ponerlos en la siguiente línea. Crowther y Walden diseñaron rápidamente los algoritmos críticos, aquellas reglas básicas que solventaban el procesado y enrutamiento de los paquetes. Así determinaron que no necesitarían más de 150 líneas de código para procesar un paquete a través de los imps. Obviamente debían confiar en sus diseños hasta disponer el dispositivo real donde probarlos. Otra tarea clave, que no dependía de la BBN, era la subcontrata de AT&T que dependía directamente de Roberts, miembro distante pero a la vez fuerza vital del proyecto, que debía hacer los arreglos necesarios para disponer de las líneas de 50-kbit en cada servidor para la fecha en la cual los imps estarían preparados. La interfaz de usuario entre servidor e IMP era responsabilidad de cada sitio, pues no era posible desarrollar una única con ordenadores de distintos fabricantes, eso sí, el equipo debía darles a cada uno la hoja con las especificaciones de la comunicación de servidor a IMP antes de que estos comenzaran con lo suyo. El encargado de escribir dicha especificación fue Bob Kahn, antiguo ingeniero del MIT que trabajaba ahora en el equipo y que mantenía contacto regularmente con Roberts acerca del estado del proyecto. Para la detección de errores idearon el aún usado y conocido checksum o suma de verificación, que como es de esperar consiste en enviar en el conjunto de datos un valor suma, como podría ser por ejemplo el número de unos, para que en la recepción se recuenten y se comparen con dicho valor. Al no disponer de indicaciones previas sobre las posibles tasas de error, obviamente, Kahn y Roberts