Resumen

  • El RFC 1693, Experimental de noviembre de 1994, examinó un servicio de orden y fiabilidad parciales. Su consulta inventada de cuatro registros admitía uno, dos, cuatro o 4! = 24 órdenes, según el criterio elegido.
  • La nota inicial del IESG no recomendó implementar las modificaciones de TCP propuestas; sí encontró útil, fuera de TCP, el examen de datos que llegan desordenados o incompletos.

La ventanilla no entrega el expediente que tiene delante

La promesa de un flujo fiable y ordenado tiene buenos motivos. El RFC 793 define la secuencia que TCP presenta a la aplicación. Si falta una parte anterior, la posterior espera su turno, aunque ya esté en el receptor. Para un archivo, esa disciplina suele ser exactamente lo pedido. Para los resultados de una consulta que pueden intercambiar posiciones, la disciplina se parece a una ventanilla que retiene un expediente completo hasta que aparezca el número anterior.

T. Connolly, P. Amer y P. Conrad eligieron cuatro registros para enseñar dónde aprieta el zapato. Ordenados por cuatro nombres distintos de vendedores, solo hay una salida válida. Ordenados por localidad, con dos registros de una misma ciudad, hay dos. Si se ordenan por una descripción repetida en dos pares, hay cuatro. Sin ORDER BY, valen todas las permutaciones de cuatro objetos: 24. Son posibilidades combinatorias de una tabla ficticia, no resultados de una prueba de velocidad. El número cambia porque cambia la relación que la consulta impone entre las fichas.

Una relación de orden parcial expresa justo eso. Ciertos objetos tienen que ir antes que otros; los que no guardan esa dependencia pueden pasar en cualquier sentido. El emisor y el receptor necesitarían comunicar o negociar esas condiciones. Después, el receptor tendría que comprobar qué objeto ha satisfecho todos sus requisitos previos. No basta con soltar los datos a lo loco; tampoco hace falta poner a cuatro pasajeros en una única fila cuando la consulta acepta varias.

El artículo añade una segunda perilla: fiabilidad. Una búsqueda puede pedir que aparezcan todos los registros, aunque su orden sea flexible. Una transmisión multimedia puede conservar el orden de un canal y aceptar la pérdida de una imagen que ya caducó. El RFC recorre ejemplos de vídeo, dos canales de audio, texto, imagen de lengua de signos y refresco de ventanas. El contrato adecuado depende del uso de cada pieza, algo que la aplicación conoce mejor que una regla universal de entrega.

La propuesta situó ese contrato en una conexión TCP modificada y estudió cómo iniciar la conexión frente a un par corriente. También examinó el ahorro posible de entregar piezas elegibles antes de que se rellene un hueco ajeno. La aritmética de los cuatro registros no cuantifica dicho ahorro. Tampoco se convirtió, por aparecer en un RFC, en una prestación adoptada de TCP.

Al principio del texto figura la decisión que impide inventarle un final triunfal. El director del área de Transporte y su directorio no recomendaron implementar los cambios de TCP. En la misma nota consideraron útil estudiar el manejo de datos desordenados e incompletos fuera de ese protocolo. Una buena pregunta y una implementación concreta recibieron juicios diferentes. Esa separación es la noticia histórica; el segundo registro seguía esperando mientras todos discutían el reglamento de la fila.