Кратко

  • Команда IHAVE сначала предъявляет Message-ID. Сервер может узнать уже известную статью, отложить решение или запросить полное тело.
  • Запрос тела не равен окончательному приёму. После проверки сервер вправе подтвердить передачу, сообщить о временной неудаче или отказать; положительный код также не обещает вечного хранения.
  • Потоковые CHECK и TAKETHIS позволили вести много обменов одновременно. Они ускорили канал, не передав отправителю власть над политикой и диском получателя.

От почтового мешка к двум воротам

Ранний Usenet жил в ритме накопления и пересылки. Узел мог связаться с соседом ненадолго, поэтому повторная передача уже известной статьи стоила дорого. Логичный ход состоял в том, чтобы сначала перечислить короткие идентификаторы, а полные тексты отправить только по запросу.

RFC 1036 описывает управляющие сообщения ihave и sendme. Система A сообщала Message-ID доступных статей, система B просила недостающие. Идентификаторы объединяли в пакеты: служебные расходы одного предложения могли оказаться сравнимыми с небольшой статьёй.

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

IHAVE сделал предварительный ответ явным

RFC 977 перенёс принцип в команду NNTP. Клиент посылает IHAVE и Message-ID. Сервер отвечает 335, если хочет получить статью, 435, если она не нужна, или 436, если предложение следует повторить позже.

Только после 335 передаётся полное тело. Тогда сервер видит группы, Distribution, заголовки, размер и реальные байты. Следует второй ответ: 235 при успешной передаче, 436 при временной неудаче, 437 при отказе без запроса повторения. Возможны отказ из-за нежелательных групп или области распространения, нехватки диска, чрезмерной длины либо повреждённых заголовков.

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

Три предложения показывают все ветви

Пусть сосед предлагает три Message-ID. Первый уже найден в истории, и тело не передаётся. Второй встречает временную проблему, сохраняя возможность повторной попытки. Третий получает 335 и пересекает канал полностью.

После чтения третьего тела сервер обнаруживает недопустимую область распространения и отвечает 437. В этой последовательности нет противоречия: предварительное желание увидеть объект не было обещанием его хранить. Напротив, протокол сохранил точное место, где предварительное решение стало окончательным.

Если журнал хранит только 437, он не объясняет, почему был потрачен канал. Если хранит только 335, он ложно объявляет приём. Нужны оба ответа, стадия и отпечаток переданных байтов.

Современный NNTP не додумывал успех

RFC 3977 закрепил двухэтапную схему. IHAVE нельзя конвейеризовать: клиент ждёт первый ответ, при необходимости отправляет статью и ждёт окончательный ответ. Отсутствующий ответ трактуется как временная неудача, а не как молчаливое подтверждение.

Это правило важно после обрыва соединения. Отправитель может повторить предложение, поскольку не знает итог. Получатель должен распознавать повтор того же аргумента или статьи, чтобы восстановление не породило лишние копии.

Документ также отделяет транзитный IHAVE от POST, которым в систему вводят новую статью. Транзитный сервер принимает решение внутри отношений двух площадок. Он не удостоверяет автора для всего мира и не обещает доставку каждому следующему узлу.

235 закрывал обмен, но не будущее

RFC 977 предупреждает: сервер способен ответить 235, а затем при дальнейшей обработке обнаружить неприемлемость статьи и молча удалить её. Код доказывает успешное завершение определённой транзакции, но не постоянное владение копией.

RFC 4644 сохраняет ту же границу для потокового режима. Даже положительный 239 после TAKETHIS не исключает последующего удаления. Для доказательства хранения нужны новые наблюдения: наличие в spool, выдача читателю или предложение следующему соседу.

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

CHECK и TAKETHIS ускорили эволюцию

Последовательные ожидания IHAVE плохо использовали канал с большой задержкой. RFC 4644 ввела CHECK, чтобы спросить о нужности Message-ID, и TAKETHIS, чтобы передать тело и получить итоговый ответ. Множество проверок и передач теперь могли находиться в работе одновременно.

Однако ответ CHECK оставался рекомендацией. Получатель не должен был полагаться на безусловное послушание клиента. Политика площадок или адаптивная стратегия могла разрешать TAKETHIS без предварительного CHECK; окончательное решение о теле всё равно оставалось у получателя.

Потоковая передача убрала простой между воротами, но не снесла ворота. Техническая оптимизация не дала отправителю права размещать материал на чужом диске.

Старый контроль уступил место договорённости площадок

RFC 5537 отмечает, что управляющие сообщения ihave и sendme в Интернете в основном устарели, хотя сохранялись в некоторых средах UUCP. Современные площадки заранее договаривались, какие статьи и каким транспортом обменивать.

В этой договорённости находились иерархии, области распространения и фильтры. Message-ID её не содержал, а ответ 335 её не создавал. Команды исполняли отдельную передачу внутри более широких отношений между операторами.

Историческая линия от ihave и sendme к IHAVE, а затем к CHECK и TAKETHIS — не просто рост скорости. Это сохранение границ при каждой оптимизации. Получатель мог экономно запросить объект, осмысленно проверить его и независимо решить судьбу своей копии.

Источники