Кратко

  • RFC 9171 различает приём, пересылку, локальную доставку, удаление и отчёты о состоянии; отчёт говорит о состоянии, которое утверждает сформировавший его узел.
  • BPv7 сам по себе не гарантирует доставку end-to-end, а custody transfer больше не является состоянием базового протокола. Приём не доказывает хранение, обработку приложением, полномочие или внешний результат.

Сети с длительными разрывами связи требуют точного учёта глаголов. Связь может исчезнуть, задержка может быть большой, а следующего соседа может не быть в момент отправки. Bundle Protocol Version 7 переносит данные приложения вместе с информацией, которая может сделать их пригодными к использованию при доставке. В такой среде слова «отправлено» и «готово» сами по себе не образуют проверяемой цепочки доказательств.

Поэтому RFC 9171 даёт разным событиям разные названия. Transmission — попытка Bundle Protocol Agent, BPA, добиться доставки копий узлам endpoint. Forwarding — продолжительное использование одного или нескольких convergence-layer adapter, чтобы другой узел получил копию. Delivery имеет ещё более узкий, локальный смысл: полезная нагрузка и относящиеся к ней метаданные представлены application agent узла в соответствии с локальной registration. Удаление, отбрасывание и retention constraint, препятствующие отбрасыванию, являются отдельными состояниями.

Это не стилистическая тонкость, а граница каждого доказательства. Пересланный bundle не обязательно принят следующим узлом. Принятый bundle не обязательно может быть доставлен локально. Нагрузка, представленная application agent, не обязательно обработана им. И отчёт об одном из этих событий не обязательно дошёл до того, кто должен реагировать. Если назвать всё это «доставлено», интерфейс станет проще, но место смены ответственности исчезнет из записи.

Процедура приёма показывает первую границу. Когда BPA принимает bundle от другого узла, он добавляет retention constraint “Dispatch pending”. Если запрошен отчёт о приёме и отчётность включена, BPA должен сформировать отчёт о приёме для endpoint report-to. Это позволяет утверждать только конкретный факт: данный узел начал предписанную обработку принятого bundle.

Дальнейшее вовсе не гарантирует сохранение bundle. BPA проверяет приложенные CRC. Если bundle сформирован некорректно или приложенный CRC не совпадает с вычисленным при приёме, BPA обязан удалить bundle и пропустить остальные шаги приёма. Неподдерживаемый extension block также может вызвать отчёт, а затем — в зависимости от его управляющих флагов — удаление bundle или самого блока. Поэтому наличие отчёта о приёме нельзя превратить в доказательство, что объект был корректен, сохранён, переслан или передан приложению.

У пересылки другой предмет. BPA выбирает узлы и adapter, затем запрашивает отправку. Вывод о том, привело ли завершение процедур отправки данных к успешному forwarding, специфичен для реализации; при неуспехе BPA может предпринять новую попытку в соответствии с локальной конфигурацией. Отчёт о пересылке описывает именно это состояние. Он не является квитанцией следующего узла, гарантией сохранения маршрута или свидетельством прибытия к конечному endpoint.

На стороне назначения граница ещё очевиднее. Локальная доставка зависит от состояния registration, соответствующей endpoint назначения. Fragments могут сначала требовать сборки; пассивная registration или специфическая для реализации ошибка доставки может отложить доставку либо отказаться от неё. Даже когда сформирован отчёт о доставке, RFC прямо говорит: он означает лишь передачу полезной нагрузки application agent, но не обработку этой нагрузки агентом.

Для автоматизированного процесса это существенная оговорка. Приложение по собственным правилам может проверить данные, поставить их в очередь, отклонить, отложить, преобразовать или проигнорировать. Состояние BP не сообщает, какое действие произошло. Оно не называет владельца делового решения, не доказывает рассмотрение результата уполномоченным лицом и не подтверждает выполнение необратимой команды. Если эти факты важны, приложение и система, принимающая решение, должны создавать и хранить собственные записи.

Отчёты о состоянии полезны, но не образуют всеведущий журнал. RFC требует, чтобы их генерация по умолчанию была выключена: большое число запросов может породить чрезмерный трафик. Даже после включения решение сформировать запрошенный отчёт остаётся на усмотрение BPA. Если отчёт содержит время, оно сообщено локальными часами узла и относится к вопросам реализации. Следовательно, отчёт — ограниченное утверждение одного узла, переносимое как другой bundle к report-to endpoint; это не глобальная хронология без потерь и не доказательство, что предполагаемый читатель его получил.

Историческое сопоставление с custody также важно. Экспериментальная RFC 5050 определяла custody acceptance и custody signals. Таблица RFC 9171 оставляет соответствующие флаги запросов значениями версии 6, а Приложение A говорит, что custody transfer перенесена в Bundle-in-Bundle Encapsulation. Базовый BPv7 сохраняет полезные механизмы удержания, пересылки, локальной доставки, отчётности и расширений, но не превращает приём в принятие хранения. Тот, кому нужна устойчивая обязанность хранения, должен назвать механизм, условия и обработку ошибки; её нельзя вывести из бита приёма.

Наиболее широкое ограничение сформулировано прямо: Bundle Protocol сам не обеспечивает доставку к назначению. Надёжные протоколы convergence layer способны уменьшать потери между соседями; для гарантии end-to-end требуются расширения BP и/или механизмы уровня приложения. Это не скрытый недостаток, а честное распределение ответственности. Протокол описывает, что BPA сделал с bundle в определённой точке, и не притворяется доказательством последующих решений приложений, людей или организаций.

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

Различение Lu Heng между представлением, локальным решением и работающей реальностью здесь полезно как редакционная дисциплина. Отчёт BP представляет ограниченное протокольное состояние. Ему следует доверять в этих пределах, но не поднимать его до декларации полномочия или успеха. Работающие системы становятся устойчивее, когда отделяют наблюдённое событие от последствия, которое другому участнику ещё предстоит выбрать и осуществить.

Источники