Кратко

  • Экспериментальный RFC 1693 от ноября 1994 года исследовал транспорт с частичным порядком и частичной надёжностью. В придуманном запросе с четырьмя записями в зависимости от сортировки допустим один, два, четыре или 4! = 24 варианта ответа.
  • Примечание IESG в начале документа не рекомендовало осуществлять предложенные изменения TCP. При этом разбор данных, приходящих не по порядку или не полностью, был признан полезным и вне TCP.

Клерк видит готовую бумагу и всё равно ждёт

Упорядоченный надёжный поток байтов — обещание TCP, изложенное ещё в RFC 793. Пока отсутствует ранний фрагмент, более поздний не передают приложению, даже если получатель уже его видит. Для сборки файла такое правило удобно. Для независимых результатов запроса оно порой напоминает чиновника: бумага на столе, но окно закрыто, поскольку предыдущий посетитель ещё не подошёл.

T. Connolly, P. Amer и P. Conrad взяли четыре записи: Anderson из Атланты, Baker и Crowell из Бостона, Dykstra из Вашингтона. Первые две относятся к Camping Gear, последние две — к Sportswear. Сортировка по четырём разным именам продавцов оставляет только порядок 1–2–3–4. По городам Baker и Crowell могут поменяться местами: допустимы два порядка. По описанию местами могут меняться и записи 1 с 2, и записи 3 с 4: получается четыре. Без ORDER BY разрешены все 4! = 24 перестановки. Это число допустимых последовательностей в учебном примере, а не измерение задержки или ускорения TCP.

«Частичный порядок» сохраняет обязательные связи: некоторую запись надо выдать после её предшественника, независимые записи можно менять местами. Участникам соединения понадобилось бы передать или согласовать эти связи. Получатель при появлении очередного объекта проверял бы, выполнены ли условия для его выдачи. Так система не бросает карточки вразнобой, но и не требует одной колонны для всех.

Надёжность составляет отдельный параметр. База может требовать в конце все записи, допуская разные последовательности. В мультимедийной передаче порядок внутри канала может быть важен, зато устаревший кадр допустимо потерять. RFC рассматривает видео, два звуковых канала, текст, изображения жестовой речи и перерисовку окна. Смысл потери и зависимости задаётся тем, как приложение использует элементы, а не одним универсальным порядком байтов.

Авторы разобрали соединение с частичным порядком внутри изменённого TCP и возможность устанавливать связь с обычным партнёром. Они исследовали потенциальную пользу ранней выдачи объекта, который раньше задерживался за чужим пропуском. Расчёт перестановок не доказывает выигрыш во времени и не описывает развёрнутую функцию стандартного TCP. Исследование появилось как экспериментальный RFC вместе с оговоркой тех, кто оценивал именно предложенное место реализации.

Перед основным текстом IESG сообщила: руководитель направления Transport и его группа не рекомендуют воплощать изменения TCP. Анализ неполных и пришедших в неправильном порядке данных они сочли ценным за пределами TCP. Получились две разные оценки в одном документе. Исследователи хорошо заметили проблему; предложенный ответ для конкретного протокола поддержки не получил. Вторая запись на столе по-прежнему спрашивает: почему ей надо ждать первую?