Кратко

  • ETFTP собирал множество packets в buffer и bursts, чтобы один дорогой доступ к каналу перенёс большой объём данных; получатель отвечал на границе buffer и перечислял лишь отсутствующие номера.
  • CONTROL_OK, CONTROL_RESEND, наибольший непрерывный номер CONTROL и NULL-ACK были локальными квитанциями. Они не доказывали весь файл, личность другой стороны, безопасность или причину потери.
  • Данные 1993 года относились к точечной линии 16 кбит/с. RFC прямо сообщал об отсутствии проверки пароля и о том, что безопасность прототипа была упущена.

Ответ требовал ещё одной синхронизации

На описанном тактическом спутниковом пути синхронизация радиостанции и криптоустройства перед передачей занимала около 1,25 секунды. Распространение через спутник добавляло примерно 500 миллисекунд к полному кругу. Полудуплекс не позволял отправить ответ параллельно данным: направление приходилось разворачивать.

ETFTP экономил число таких операций. Файл читался в buffers, buffer делился на blocks, каждый block становился DATA packet, а несколько packets объединялись в burst. Последний block buffer отмечался как LDATA. При полном приёме следовал CONTROL_OK; при наличии дыр CONTROL_RESEND содержал номер buffer и точный перечень отсутствующих packet numbers.

Так протокол ограничивал смысл свидетельства. RESEND показывал текущие пробелы в одной приёмной копии buffer. OK принимал именно этот buffer. Для конца всей передачи оставалась отдельная пара QUIT и DONE.

Размеры управляли разными рисками

Большой buffer уменьшал число подтверждений, но требовал памяти и дольше занимал канал. Большой burst удерживал передатчик включённым, однако мог заполнить промежуточные очереди. Большой packet сокращал долю заголовков, но делал каждую ошибку BER дороже.

Автоадаптация реагировала на наблюдаемый результат. Если половина или больше blocks требовала повторения, реализация сначала делила packet size пополам, затем уменьшала burstsize, а после приближала burstrate к tight timer. Если 99% packets приходили без повторения, размер можно было увеличить. CONTROL_OK предлагал значения, а NULL-ACK подтверждал их принятие отправителем.

Это узкий общий слой: номера, список дыр, параметры и граница перехода. Но подтверждённое предложение ещё не равно исполнению. Только последующая серия packets показывает, применили ли оба конца значения на одном рубеже.

Непрерывный номер охватывал лишь начало истории

DATA и LDATA несли наибольший непрерывно полученный номер CONTROL. Поле подтверждало префикс управляющих сообщений без дыр. Оно ничего не говорило о следующих сообщениях, ещё не обнаруженных потерях данных, содержимом диска или завершении файла.

Таймер тоже не называл причину. Модель зависела от заданного baudrate, введённого либо измеренного radiodelay, а при повторных timeout ожидание росло на пять секунд. Срабатывание показывало нарушение временного ожидания, но не отделяло ошибки радио от конкуренции, переполнения очереди, неверной оценки и задержки программы. Список RESEND отвечал на вопрос «чего не видно», но не «почему».

Running-Code Primacy проводит здесь полезную границу. Опубликованный RFC задаёт интерпретацию квитанции; наблюдаемый поток показывает, была ли эта интерпретация реализована.

Эксперимент оставался экспериментом

В таблицах использовался файл 101 306 байт, зашифрованная линия 16 кбит/с, radiodelay две секунды и несколько сочетаний размеров. Радиостанции соединялись коаксиальным кабелем, образуя «clean» канал с BER 10e-5. Максимум 10 432 бит/с был получен при buffer 131 072 байта, packets по 2 048 байт и шестнадцати packets на burst; время включало соединение, восстановление и закрытие.

Эти цифры не доказывали распространённость, multicast, справедливость общего эфира или превосходство над современными системами. RFC предупреждал, что максимальный p-persistence для двух терминалов не подходит многим пользователям. В тексте также осталась несогласованность: регулируемый packet size указан как 16–1 448 полезных байт, тогда как таблицы включают 2 048. Её нельзя устранять догадкой.

Безопасность имела ещё более жёсткую границу. ETFTP не проверял пользователя и пароль, повторял проблемы TFTP, а экспериментальный сервер требовал владельца root и setuid root. Авторы признали, что безопасность была проигнорирована. Checksum, connection ID, порт и sequence связывали сообщения с состоянием, но не удостоверяли участника и не разрешали доступ к файлу.

Исторический смысл RFC 1986 — в переводе физической задержки в явный протокольный бюджет. Длинная фаза данных сокращала развороты, короткий ответ называл пробелы. Но сила этих квитанций зависела от скромности выводов: принятие buffer, завершение файла, причина сбоя и доверие к стороне оставались разными утверждениями.

Источники