Resumen

  • El PING de Fuzzball que Dave Mills describió en 1983 llevaba años midiendo redes con varios tipos de sondas y herramientas de análisis; el ping de Mike Muuss para BSD fue otra implementación, de alcance distinto.
  • Muuss sitúa su trabajo en diciembre de 1983. Su versión necesitó soporte del kernel para sockets ICMP sin procesar y presentó las respuestas como tiempos de ida y vuelta y pérdidas fáciles de inspeccionar.

Una red parece fallar. La pregunta práctica es más estrecha: ¿un destino contestará a esta sonda, desde este punto, en este momento? Para responder hay que elegir un paquete, medir el tiempo, relacionar cada respuesta con su petición y mostrar lo observado. La historia de ping reúne dos herramientas que abordaron esa tarea desde lugares distintos. El nombre compartido puede ocultar que una servía a la investigación y la otra a la operación diaria de un host Unix.

La base del protocolo ya existía. RFC 792, publicado en septiembre de 1981, definió ICMP Echo y Echo Reply. El emisor podía incluir datos, un identificador y un número de secuencia; el respondedor devolvía esos valores, útiles para emparejar cada respuesta con su petición. El documento no inventó el sondeo repetido ni una pantalla de terminal, y tampoco convirtió ICMP en una prueba general de que una aplicación funciona. El propio RFC presenta ICMP como información sobre el entorno de comunicación IP, sin garantizar la entrega de datagramas o mensajes de control.

Dave Mills ya utilizaba un PING en sus sistemas Fuzzball. En RFC 889, de diciembre de 1983, lo llama el PING original, expande el nombre como “Packet InterNet Groper” y dice que llevaba seis años usándose en mediciones de Internet y redes cliente. Mills lo describe como uno de varios paquetes instalados en un host de medición LSI-11. Podía emitir distintos tipos de sondeo, incluido ICMP Echo, procesar las respuestas, guardar tiempos y otros datos, y producir histogramas y trazas en tiempo real. Era un instrumento de investigación integrado con otros medios de análisis, no solo una orden breve.

Los experimentos de RFC 889 permiten ver la disciplina detrás de esa instrumentación. En octubre y noviembre de 1983 se midieron rutas usando Echo con marcas de tiempo. Para cada ciclo se enviaba un paquete de cierta longitud, se esperaba su respuesta y se anotaba el tiempo transcurrido; una ejecución reunía 512 ciclos. El propósito era estudiar cómo la longitud del paquete y el camino afectaban la demora, las pérdidas y el cálculo del timeout de retransmisión TCP. Mills advierte que la demora de red debe distinguirse de las colas que puede haber dentro de los propios hosts.

Sin ese contexto, una cifra de latencia parece explicar más de lo que realmente mide.

El relato de Mike Muuss describe otro uso. Recuerda que en julio de 1983, durante una reunión de DARPA en Noruega, Mills mencionó las pruebas temporizadas de ICMP Echo en sus Fuzzball LSI-11. En diciembre, un comportamiento extraño de la red IP del Ballistic Research Laboratory llevó a Muuss a escribir PING para 4.2a BSD UNIX. Tanto la conversación como el orden exacto de los hechos proceden del recuerdo retrospectivo de Muuss. Su programa requería un socket Berkeley SOCK_RAW/AF_INET para ICMP. Compilaba, pero el kernel aún no ofrecía ese soporte. Muuss cuenta que añadió la capacidad esa noche. Antes de que pudiera enviar su primer paquete, su colega Chuck Kennedy ya había identificado y corregido el fallo del hardware local.

Ahí cambia el puesto de trabajo. El PING de Fuzzball formaba parte de un entorno de medición que permitía guardar y estudiar series. El programa BSD de Muuss hacía que un operador pudiera repetir un Echo desde su host y leer cada respuesta en pantalla: número de secuencia y tiempo transcurrido, seguidos de paquetes enviados y recibidos, pérdida y tiempos de ida y vuelta mínimo, medio y máximo. El protocolo aportaba la solicitud y la respuesta; la utilidad sumaba repetición, reloj y una síntesis comprensible. Muuss afirma que Berkeley recibió el código y los cambios del kernel y que el programa pasó a formar parte de Berkeley UNIX.

Su testimonio respalda ese alcance, pero no fija la adopción en cada versión ni demuestra que todos los sistemas posteriores se comportaran igual.

También conviven dos explicaciones del nombre. Muuss dice que pensó en el sonido del sonar y la ecolocalización. RFC 889 llama “Packet InterNet Groper” al PING anterior de Mills; Muuss dice que solo oyó de segunda mano que Mills quizá propuso esa expansión. Conviene conservar ambas pistas y no inventar una única escena de bautismo: las fuentes enlazan la expansión con Fuzzball y describen la asociación acústica que Muuss hizo con su versión BSD.

Una respuesta Echo significa que un respondedor devolvió esta sonda con los datos y campos que permiten relacionarla con la petición. Una serie de pings permite observar, desde un origen y durante un intervalo concretos, variación del tiempo y respuestas ausentes. No prueba que la web, el correo u otra aplicación estén disponibles; no autentica la identidad del respondedor ni recorre todas las rutas. La ausencia de respuesta tampoco demuestra que el host no exista: puede intervenir un filtro, una política, la congestión o el propio sistema. Fuzzball obtenía valor interpretando series y trazas; BSD hizo más fácil lanzar la observación.

La accesibilidad del comando no amplía el significado de la evidencia.

Por eso 1983 no representa el paso de “no había ping” a “Muuss inventó ping”. Echo ya estaba normalizado en RFC 792 y el testimonio contemporáneo de Mills documenta un PING Fuzzball anterior. Muuss adaptó la idea a un diagnóstico inmediato en BSD y añadió el soporte de kernel que su implementación necesitaba. La pequeña herramienta cambió quién podía hacer la pregunta y con qué rapidez; aún hay que distinguir una sonda contestada de un servicio que funciona.

Fuentes