Кратко

  • RFC 2188 разделяет роли invoker и performer так, что состояние одной стороны не всегда является доказательством состояния другой: в acknowledged-режиме invoker способен увидеть успешный RESULT, даже если performer позднее фиксирует FAILURE.
  • Для эксплуатации этого недостаточно свести наблюдение к одному коду возврата: Invoke ID, таймеры, повторы, журналы обеих сторон и отдельная проверка прикладного эффекта образуют разные уровни доказательности.
  • Особенно опасно превращать локальное состояние одного конца в универсальное определение успеха: такое решение упрощает мониторинг, но закрепляет слепые зоны в повторных операциях, расследовании сбоев и проверке фактического результата.

ESRO как протокол коротких удалённых операций

RFC 2188 был опубликован в сентябре 1997 года в статусе Informational, а не Internet Standard. Документ не проходил рассмотрение рабочей группой IETF, а примечание IESG отдельно обращает внимание на ограничения масштабируемости. Поэтому его полезно читать прежде всего как конкретную инженерную конструкцию и описание модели поведения, а не как утверждение о всеобщем стандарте для удалённых операций.

Описанный в нём Efficient Short Remote Operations, или ESRO, предназначен для надёжных удалённых операций без предварительного установления соединения поверх UDP либо другого ненадёжного транспорта без соединений. Среди сред, для которых такая экономия накладных расходов имела значение, документ рассматривает беспроводные условия, включая CDPD. ESRO определяет сегментацию и сборку, сцепление и разделение сообщений, мультиплексирование приложений; для UDP указан порт 259.

В модели протокола стороны имеют разные роли. Инициирующая сторона называется invoker, исполняющая — performer. Уже это различие важно для интерпретации журналов: одинаковое слово вроде «успех» не обязано обозначать одно и то же событие для двух участников.

Трёхсторонний режим и расхождение наблюдений

В acknowledged-режиме используется трёхсторонний обмен. После отправки RESULT или ERROR performer не считает взаимодействие полностью завершённым на уровне протокола до получения подтверждения от invoker.

Именно здесь появляется ключевая асимметрия знания. Performer может получить FAILURE, если RESULT или ERROR не дошёл до партнёра, если до него не дошло ответное подтверждение либо если локальный поставщик услуг сообщил о сбое. Эти варианты внешне сходятся в одном состоянии performer, но означают разные истории обмена.

Следствие особенно важно: FAILURE на стороне performer не доказывает, что invoker не получил успешный результат. RESULT мог дойти до invoker, invoker мог принять его как успех, а обратное подтверждение — потеряться. В такой последовательности одна сторона знает, что получила результат, а другая не располагает доказательством этого факта.

Это и есть endpoint-relative knowledge — знание, истинное относительно конкретной конечной точки и доступной ей истории событий. Оно не является ошибочным только потому, что не совпадает с наблюдением партнёра. Ошибка возникает позже, если локальное состояние начинают трактовать как полную картину распределённой операции.

Для acknowledged-режима RFC 2188 задаёт и направленную связь другого типа: FAILURE у invoker означает FAILURE и у performer. Но из этого нельзя выводить общий закон симметрии для любых распределённых протоколов. Это свойство именно рассматриваемой модели состояний, а не основание считать все наблюдения двух сторон взаимозаменяемыми.

Двусторонний режим: подтверждение без новой информации партнёра

В non-acknowledged-режиме обмен двусторонний. Для performer подтверждение RESULT или ERROR не несёт нового свидетельства от invoker; оно означает локальное завершение соответствующей работы протокола.

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

В этой модели FAILURE performer предусмотрен только как следствие локального сигнала поставщика услуг. FAILURE у invoker, в свою очередь, может означать отсутствие ожидаемого возврата либо локальную проблему. Но ни одно из этих наблюдений само по себе не устанавливает, произошло ли фактическое исполнение операции и был ли прикладной результат зафиксирован.

Три разные реальности одной операции

Для корректного чтения ESRO полезно строго разделять три уровня.

Первый — транспортная реальность. Она отвечает на вопросы о доставке или недоставке конкретных протокольных блоков, потерях и локальных сигналах транспортной среды.

Второй — реальность протокола удалённых операций. Здесь находятся роли invoker и performer, RESULT, ERROR, FAILURE, Invoke ID, режим обмена и правила подтверждения.

Третий — прикладная или бизнес-реальность. Она отвечает на иной вопрос: произошло ли требуемое действие в системе, стало ли оно окончательным и какое состояние имеет объект, с которым работала операция.

RFC 2188 не превращает первые два уровня автоматически в третий. Даже если invoker получил RESULT, это само по себе не является доказательством окончательного commit прикладного эффекта. И наоборот, отсутствие подтверждённого протокольного результата не доказывает, что приложение ничего не изменило.

Invoke ID связывает конкретный вызов с соответствующим результатом и тем самым помогает реконструировать протокольную историю. Но он не доказывает бизнес-успех. Это идентификатор корреляции операции, а не свидетельство окончательного состояния прикладных данных.

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

Таймеры и повторы как часть границы доказательности

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

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

Именно поэтому RFC 2188 допускает отдельную проверочную операцию как средство выяснить состояние после неоднозначного исхода. Такой подход принципиально отличается от предположения «не получил подтверждение — значит, ничего не произошло». Проверка переносит вопрос с уровня локального протокольного наблюдения на уровень фактического состояния, которое действительно важно приложению.

Соседние документы без ложной генеалогии

RFC 2524 позднее описывает руководство по эффективному использованию почты поверх ESRO. Это подтверждает инженерный замысел применения ESRO в конкретном контексте, но не является свидетельством широкого распространения самого протокола.

RFC 1831, описывающий ONC RPC, полезен как соседний материал для сопоставления моделей удалённого вызова. Однако его нельзя представлять ни как заявленного прямого предшественника ESRO, ни как неизбежную замену. Замороженный набор фактов позволяет говорить о сравнении инженерных подходов, но не о доказанной линии наследования.