Resumen

  • ETFTP reunía muchos packets en un buffer y varios packets en cada burst, para aprovechar una sola activación costosa del canal; el receptor respondía al buffer, no a cada packet.
  • CONTROL_RESEND enumeraba huecos y CONTROL_OK aceptaba un buffer. Ni esos mensajes, ni NULL-ACK, ni el mayor número CONTROL consecutivo demostraban por sí solos el archivo completo, la identidad o la causa de pérdida.
  • Las mediciones de 1993 pertenecían a un montaje punto a punto de 16 kbps. El propio RFC admitía que no había contraseña y que la seguridad del prototipo se había pasado por alto.

Cada respuesta obligaba a reconstruir el sentido

El camino táctico descrito requería aproximadamente 1,25 segundos para sincronizar radio y equipo criptográfico antes de transmitir. La propagación por satélite añadía alrededor de 500 milisegundos al recorrido de ida y vuelta. Al ser semidúplex, el receptor no podía confirmar mientras seguían entrando datos en el otro sentido.

ETFTP redujo el número de inversiones agrupando trabajo. Cargaba el archivo en buffers, dividía cada buffer en blocks, convertía cada block en un DATA packet y concatenaba packets en bursts. LDATA señalaba el último block del buffer. Solo entonces el receptor enviaba CONTROL_OK, si no faltaba nada, o CONTROL_RESEND, con el número del buffer y una lista concreta de packet numbers ausentes.

La lista daba una evidencia útil pero parcial: era la fotografía del buffer que poseía el receptor. Un OK cerraba esa unidad, no toda la transferencia. El cierre global todavía exigía QUIT del emisor y DONE del receptor.

El protocolo podía encoger sin adivinar el motivo

Buffer, burst y packet respondían a problemas distintos. Un buffer grande reducía acuses y giros, pero consumía memoria. Un burst largo mantenía el transmisor activo, aunque podía llenar colas intermedias. Un packet grande amortizaba cabeceras en un enlace limpio, pero perdía más datos cada vez que el BER lo dañaba.

Con autoadaptación, si la mitad o más de los blocks de un buffer necesitaban reenvío, la aplicación primero partía por dos el packet size, después reducía en uno el burstsize y finalmente ajustaba el burstrate a la tasa observada por el tight timer. Si el 99 % llegaba sin retransmisión, podía proponer aumentar el packet. CONTROL_OK transportaba la oferta; NULL-ACK confirmaba que el emisor aceptaba los valores válidos.

Era una superficie común pequeña: identificadores, huecos y parámetros verificables localmente. Sin embargo, aceptar no equivale a ejecutar. Un NULL-ACK no muestra que el siguiente burst haya cambiado justo donde ambos extremos esperaban. Esa prueba vive en el tráfico posterior.

Consecutivo no significa completo

Los mensajes DATA y LDATA llevaban el mayor sequence number consecutivo de CONTROL recibido. El campo cubría un prefijo sin saltos de la conversación de control. No decía que los packets del buffer estuvieran completos, que no hubiera mensajes posteriores ni que el archivo escrito coincidiera con el anunciado.

Tampoco el temporizador explicaba la causa. Sus valores dependían del baudrate indicado, el radiodelay introducido o medido y una espera que sumaba cinco segundos tras cada timeout repetido. Una alarma podía revelar que el modelo temporal había fallado, pero no separar error de radio, contención, desborde de cola, cálculo equivocado o retraso del software. CONTROL_RESEND nombraba qué no veía el receptor, no por qué.

Esta diferencia encaja con Running-Code Primacy: la definición publicada hace legible el recibo, mientras la ejecución observable demuestra si los estados realmente avanzaron juntos.

Una tabla de laboratorio no era una declaración universal

Las pruebas transfirieron un archivo de 101.306 bytes sobre un trayecto cifrado de 16 kbps, con radiodelay de dos segundos y diversas combinaciones. Las radios se unieron mediante cable coaxial para crear un enlace “clean” de BER 10e-5. La cifra máxima fue 10.432 bps usando buffer de 131.072 bytes, packet de 2.048 bytes y dieciséis packets por burst; el tiempo incluía conexión, recuperación y desconexión.

El resultado no establece adopción, multicast, convivencia entre muchos usuarios ni comparación con radio moderna. El RFC advierte incluso que el p-persistence máximo de la prueba punto a punto no debía aplicarse a un canal compartido. También conserva una inconsistencia: fija el rango ajustable del packet entre 16 y 1.448 bytes útiles, pero las tablas ensayan 2.048. No corresponde inventar una reconciliación.

La frontera de seguridad era explícita. ETFTP no validaba usuario ni contraseña, heredaba los problemas de TFTP y el servidor experimental debía pertenecer a root y usar setuid root. El texto dice que la seguridad fue omitida. Un checksum, un connection ID, un puerto o una secuencia pueden correlacionar estado; no autentican a la parte que solicita el archivo.

RFC 1986 importa porque puso precio protocolario a un límite físico. Prolongó el sentido de datos y comprimió la devolución en una lista de huecos. Su rigor no está en prometer certeza total, sino en dejar claro qué aceptaba cada mensaje. Terminar un buffer, terminar un archivo, identificar una causa y confiar en un usuario eran cuatro afirmaciones diferentes.

Fuentes