Кратко

  • MessageID должен был отличаться лишь от номеров других незавершённых запросов в том же сеансе LDAP. Все записи, ссылки и финальный результат поиска повторяли этот номер, поэтому ответы разных операций могли чередоваться.
  • Abandon имел собственный ID в оболочке и второй ID для цели, но не возвращал подтверждения. RFC 3909 добавил Cancel для случаев, когда приложению надо знать об успехе, невозможности или запоздании отмены.
  • Каждая страница paged search получала новый message ID, а продолжение сохраняла непрозрачная cookie. Номер не был учётными данными, долговечным именем запроса или доказательством отката.

Поиск был последовательностью сообщений

Слово lightweight описывало более дешёвый доступ к модели каталога X.500, а не обязательную краткость ответа. Поиск по поддереву мог вернуть множество записей, ссылки на ещё не исследованные области и лишь затем итоговый успех или ошибку.

В июле 1993 года RFC 1487 поместил каждую операцию в общую оболочку LDAPMessage. Её общим полем был целочисленный messageID, отличный от ID других ожидающих запросов в том же LDAP-сеансе. Сервер копировал значение во все оболочки ответов на этот запрос.

Число не нумеровало пакеты. Сотня найденных записей могла относиться к одному состоянию поиска. Distinguished name называл объект, тип protocol operation объяснял форму сообщения, а ID соединял полученный PDU с нужной незакрытой записью у клиента.

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

Асинхронность раскрыла назначение ID

RFC 1777 в 1995 году прямо отказался требовать синхронного поведения. Запросы и ответы нескольких операций могли обмениваться в любом порядке.

Между двумя записями поиска 26 мог прийти окончательный ответ compare 27. TCP упорядочивал байты, но не назначал сообщения прикладным операциям. Message ID превращал один транспортный поток в несколько логических.

RFC 2251 сохранил правило в LDAPv3 в 1997 году, ограничил число значением 2^31−1 и запретил повтор до финального ответа. Клиенты обычно увеличивали счётчик, однако гарантией была не монотонность, а отсутствие совпадения среди активной работы.

Поиск возвращал SearchResultEntry, SearchResultReference и SearchResultDone. Записи и ссылки могли идти вперемешку; один Done закрывал поток успехом либо ошибкой. Полученная запись ещё не свидетельствовала о полном успехе. Финальный ответ сообщал исход и обычно завершал срок жизни ID.

Ноль оставили сообщению без вопроса клиента

В 2006 году спецификацию LDAPv3 перестроили. RFC 4510 описал связь с прежним набором, а RFC 4511 зафиксировал пересмотренный протокол.

ID запроса стал явно ненулевым. Ноль зарезервировали для unsolicited notification сервера, например Notice of Disconnection. Такое сообщение не отвечало ни на один запрос и не должно было выглядеть частью вымышленной операции ноль.

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

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

Abandon точно называл цель и молчал об исходе

Abandon сам является LDAP-запросом, поэтому его оболочка получает новый MessageID. В содержимом находится другой MessageID, указывающий на ранее начатую операцию. Корреляция нового действия и выбор цели остаются разными фактами.

Ответа Abandon нет. По RFC 4511 сервер может прекратить цель. Если поиск уже передаёт записи, новые записи надо остановить и SearchResultDone не отправлять. Тем не менее сообщения, уже попавшие в транспорт, могут прийти, а некоторые операции вообще нельзя abandon.

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

Поэтому RFC 2251 откладывал повтор ID самого Abandon и цели до ответа на более поздний запрос. Этот ответ не подтверждал прекращение; он лишь показывал осторожную границу продвижения сеанса.

Cancel создал отдельный подтверждаемый исход

RFC 3909 в 2004 году определил extended operation Cancel. Он не усилил старый Abandon задним числом, а дал новый механизм приложениям, которым нужен результат.

У Cancel есть собственный ID оболочки и cancelID цели. При успехе сервер отвечает success на Cancel, а целевая операция заканчивается кодом canceled. Иные коды различают неизвестную операцию, невозможность отмены и слишком поздний запрос.

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

Bind, StartTLS, Unbind, Abandon и сам Cancel отменять нельзя. Они создают или разрушают ассоциацию, аутентификацию и защиту, внутри которых обычные ID имеют смысл. Ключ корреляции не получил власть над собственным контекстом.

Следующая страница была новой операцией

RFC 2696 особенно ясно показывает предел. Сервер помещает непрозрачную cookie в SearchResultDone. Запрашивая следующую страницу, клиент повторяет параметры поиска, но меняет messageID, передаёт последнюю cookie и может изменить размер страницы.

Каждая страница—новая LDAP-операция. Cookie переносит разрешённое сервером состояние продолжения. Старая cookie может стать непригодной, пустая завершает последовательность. Abandon может остановить текущую страницу и обесценить cookie. Для корректного закрытия всей серии отправляется новый search с размером ноль и последней cookie.

ID отвечает, какая активная операция этого сеанса породила сообщение. Cookie отвечает, с какой позиции результата разрешено продолжить позже. Имя объекта, полномочие и достоверность атрибутов требуют иных доказательств.

Предел исторического вывода

Закрытый набор источников включает RFC 1487, RFC 1777, RFC 2251, RFC 2696, RFC 3909, RFC 4510 и RFC 4511. Они подтверждают правила и их развитие, но не современную распространённость, не соответствие продукта и не исход конкретной операции.

Малое число пережило поколения протокола именно благодаря узкому мандату. Оно связывало сообщение с проверяемым состоянием. Завершение, отмена, продолжение, аутентификация и авторизация требовали отдельных свидетельств.