Resumen

  • La RFC 794 propuso que un proceso de acceso a terminal mantuviese una escucha TCP adicional mientras servía a otros usuarios, para comparar la prioridad de una nueva conexión con las ya activas.
  • Cerf ilustró el problema con una transferencia FTP ordinaria y otra de prioridad «flash-override»: el servicio receptor tendría que decidir a quién desplazar y hacerse cargo del trabajo interrumpido.

Una transferencia de archivos marcha entre X e Y. Desde Z llega al puerto FTP de X una solicitud «flash-override». El paquete SYN puede traer la noticia de que el recién llegado tiene preferencia. Sigue faltando una cuestión menos elegante: ¿qué ocurre con el usuario que estaba trabajando? En septiembre de 1981, Vint Cerf dedicó la RFC 794 a ese momento en que una etiqueta de prioridad se convierte en alguien que pierde la conexión.

Cerf abrió el texto con una pequeña excursión por sistemas saturados. Un circuito telefónico reservado ocupa capacidad aunque sus dos extremos guarden silencio; en ciertos servicios, una llamada muy prioritaria podía cortarle el paso a otra. En un centro de conmutación de mensajes, el tráfico urgente adelantaba puestos e incluso podía interrumpir una impresora. En un sistema de paquetes lleno, la prioridad permitía ordenar el tráfico que esperaba entrar. La palabra era la misma; la cosa escasa cambiaba. El lector llegaba así al terminal compartido con una pregunta mejor planteada: ¿qué recurso concreto se va a liberar?

La respuesta de Cerf en AUTODIN II empezaba con una escucha pendiente. El proceso que conectaba el terminal con el sistema, llamado THP, podría dejar un LISTEN en el puerto aun mientras existiesen conexiones activas. Al aceptar otra solicitud, vería su precedencia y decidiría si debía cerrar o abortar la conexión de menor rango para cederle sitio. Después pondría otro LISTEN. El usuario podía cambiar de conversación, como ya ocurría con conexiones múltiples en el TELNET de TENEX que Cerf citó, siempre dentro de los límites de seguridad. Había una puerta atendida y una persona capaz de mirar la sala.

TCP tenía que mostrar la precedencia de la nueva solicitud al proceso. Cerf no le entregó el mando de la evacuación. TCP presta servicio a procesos y, en general, no crea uno para atender cada solicitud entrante. Si un terminal está apagado, crearle un camarero sería un chiste caro. El THP sabe qué usuario está conectado y a qué conversación puede trasladarlo. La decisión de interrumpir, y el modo de hacerlo, vive cerca de esos hechos.

El FTP aportó la prueba de escritorio. El servidor de X podía reservar una escucha adicional mientras transfería el archivo rutinario a Y. Si la solicitud de Z encontraba el servidor lleno, FTP podía retirar al usuario menos prioritario y ocuparse de la limpieza necesaria. Sin esa escucha durante el servicio, el proceso quedaba fuera de este mecanismo de preempción. No había manera de atender la llamada preferente para decidir si otra tenía que terminar.

El privilegio también podía atascarse en casa. Si Z había agotado sus recursos FTP o TCP, la solicitud preferente ni siquiera arrancaba. Cerf puso esa decisión en el sistema local: quizá habría que liberar recursos y hasta cerrar la sesión de usuarios con menor precedencia. El rango podría pertenecer al usuario o al terminal; el sistema operativo o la implementación TCP podrían realizar la acción. La prioridad de una solicitud no abría por sí sola una plaza en dos máquinas distintas.

La pequeña RFC convirtió una consigna marcial en una secuencia verificable: escuchar, comparar, interrumpir, limpiar y volver a escuchar. El servidor no podía fingir que el archivo viejo se había evaporado. Cerf dejó el botón de expulsión al alcance del programa que conocía los muebles que iba a mover.