Resumen

  • Andrew G. Malis describió en RFC 852, de abril de 1983, una opción para ordenadores conectados a IMP C/30: si faltaban recursos para aceptar un mensaje, el IMP lo rechazaría en un máximo de dos segundos y explicaría la causa con una respuesta de transmisión incompleta, Tipo 9. El bloqueo habitual podía detener todos los envíos del ordenador hasta quince segundos.
  • La vía rápida podía alterar el orden práctico. El IMP podía aceptar un mensaje posterior antes de que el ordenador supiera que el anterior había sido rechazado. ARPANET conservaba el orden de entrega según la aceptación para mensajes de igual prioridad, origen y destino; el programa que necesitara el orden original debía hacerse cargo o elegir la modalidad larga.

Un funcionario recibe un expediente complicado y baja la persiana mientras busca un papel. Detrás espera otra persona con una gestión sencilla. La ventanilla sigue cerrada para ambos. Eso ocurría en la entrada de un IMP, el procesador que conectaba un ordenador con ARPANET. Cuando no podía reunir de inmediato los recursos necesarios para un mensaje, podía dejar de aceptar cualquier otro del mismo ordenador. El mensaje siguiente quizá necesitara recursos diferentes y pudiera salir enseguida. La persiana no preguntaba.

El bloqueo ordinario podía durar quince segundos. En RFC 852, Malis ofrecía al ordenador un límite opcional de dos. Si el IMP aún no podía procesar el mensaje, lo descartaba y enviaba una respuesta Tipo 9 con la razón; después seguía reuniendo lo que faltaba. El ordenador quedaba libre para presentar otras piezas y reintentar la primera más tarde. Esta salida no convertía un intento en una entrega. Convertía una espera muda en un rechazo reconocible y una tarea pendiente.

La decisión se expresaba en subtipos. Para un mensaje regular de Tipo 0, el subtipo 0 mantenía las facilidades habituales y el máximo de quince segundos; el 1 conservaba esas facilidades con el máximo de dos. Los paquetes «uncontrolled» tenían su pareja: subtipo 3 con el plazo largo y 4 con el corto. Esos paquetes no recibían garantía de entrega. El ordenador que pidiera el plazo reducido debía interpretar bien la respuesta Tipo 9. La especificación estaba dirigida a IMP C/30 y servía con acceso 1822 o 1822L.

Una interfaz anterior descrita como no bloqueante nunca se había implementado; RFC 852 ofrecía otra solución y pedía comentarios a los responsables de software.

La respuesta Tipo 9 distinguía averías que merecían planes distintos. Podía faltar tiempo para establecer una conexión, espacio en el IMP de destino, capacidad de una ruta congestionada o recursos en el IMP de origen. También podía haberse llenado el cupo de mensajes pendientes de una conexión. Las cuatro primeras situaciones podían dejar libres otros destinos o conexiones. Una escasez local de memoria o entradas de tabla afectaba a casi todo el tráfico controlado. Si el operador resumía todos los casos como «red ocupada», perdía la pista que le decía qué trabajo podía seguir.

El cupo concreto era de ocho mensajes pendientes de respuesta por conexión. Un noveno mensaje en esa misma conexión no podía ser aceptado hasta que hubiera sitio. El tamaño introducía otra frontera: un mensaje de más de 1.008 bits, sin contar su cabecera de 96 bits, exigía reservar espacio en el IMP de destino. Mientras ese espacio no apareciera, un mensaje más corto o destinado a otra conexión podía tener paso. El problema no era siempre la velocidad de todo ARPANET. A menudo era un recurso específico que el noveno formulario no podía conseguir.

Abrir la ventanilla antes alteraba otra cuenta: el orden. ARPANET prometía entrega secuencial para mensajes con la misma prioridad, el mismo origen y el mismo destino según el orden en que el IMP los aceptaba. El ordenador no recibía la respuesta al primer rechazo necesariamente antes de presentar el segundo mensaje. Si el segundo entraba y el primero volvía después como reintento, la secuencia de aceptación ya no coincidía con la de envío original. Malis lo dijo sin rodeos: cuando la entrega secuencial del subred era un requisito estricto, convenía no usar la opción corta.

La medida repartía el trabajo de forma nueva. El IMP podía decir pronto «este mensaje, ahora no» y explicar si faltaba una conexión, un hueco entre ocho pendientes, un búfer lejano o recursos locales. El ordenador podía seguir con otros destinos. A cambio tenía que recordar qué quedó fuera, cuándo volver a llamar y qué mensaje debía ir antes que otro. La persiana tardaba menos en levantarse; alguien tenía que llevar la libreta.