Кратко

  • RFC 3340 разделял идентификаторы в пределах живого канала BEEP и идентификаторы внутри данных сервиса APEX, способные сохранять смысл после отключения инициатора.
  • Второе приложение могло подключиться как та же конечная точка и получить ответ первому; совпавшие имя и идентификатор не подтверждали владение запросом, продолжающееся намерение или право действовать.

В разделе 6.1.1 описана почти бытовая смена дежурства. Приложение подключается к релейной сети как конечная точка, отправляет сервису данные со встроенным идентификатором транзакции, а позднее отключается. Затем другое приложение подключается под тем же именем и отправляет собственные запросы. После этого ему может прийти ответ сервиса на запрос первого приложения — со старым идентификатором внутри.

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

Идентификаторы с разной продолжительностью жизни

APEX работал поверх BEEP. В режимах «конечная точка — реле» и «реле — реле» идентификатор имел значение только в течение жизни канала BEEP. После закрытия соединения канал исчезал, а приложение переставало быть подключённым к сети. Идентификатор операции attach не переносил контекст в следующее соединение.

При обращении к сервисам APEX идентификатор мог находиться в пересылаемых данных. Сервис продолжал работу после разрыва исходного канала, поэтому RFC назвал такие идентификаторы потенциально долговечными. Чтобы снизить неоднозначность, значения, создаваемые приложениями, должны были выглядеть непредсказуемыми.

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

ok до работы с получателями

Последовательность релейной обработки тоже ограничивает смысл подтверждения. Реле сначала проверяет полномочие клиента BEEP отправлять от заявленного источника и обрабатывает опции уровня данных. Затем возвращает ok. Опции источника и каждый получатель обрабатываются позже.

В другой административной области получатель считается обработанным после установления сессии с нужным реле, передачи новых данных и получения его ok. Для локальной точки политика доступа должна разрешить связь, точка должна быть подключена, а приложение — вернуть ok после своей обработки. Это разные рубежи. Начальное принятие не является ответом сервиса, а протокольное подтверждение приложения ещё не доказывает деловой или пользовательский результат.

Опция statusRequest порождала последующие statusResponse от применимых реле через сервис отчётов. Значение all для targetHop позволяло проследить прохождение данных по сети. Такая трасса добавляла новые наблюдения, не расширяя задним числом смысл первого ok. При этом временные сведения могли раскрывать внутреннюю топологию, поэтому RFC 3342 допускал их отключение вне входов и выходов административной области.

Аутентифицированное имя не сохраняет процесс

Реле искались через DNS SRV. RFC 3340 связывал целостность релейной доставки с DNS и тем, как приложения используют DNS, а дополнительной гарантией называл аутентификацию слушателя BEEP. Политика могла разрешить аутентифицированному узлу подключаться под конкретным именем. Для сквозной аутентификации содержимое следовало подписывать.

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

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

Почему документ стал Historic

RFC 3340 вышел в июле 2002 года как документ Standards Track. Вместе с RFC 3341, RFC 3342 и RFC 3343 он описывал ядро APEX, доступ, опции и присутствие. В истории IETF за 29 июля 2012 года записана причина перевода всех четырёх документов в Historic. Насколько было известно IETF, их реализации не развёртывались, а функции APEX предоставлял широко развёрнутый XMPP, описанный в RFC 6120 и RFC 6121.

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

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

Источники