RFC: 4533
Оригинал: The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operatio
Категория: Экспериментальный
Дата публикации:
Автор:
Перевод: pro-ldap.ru

RFC 4533, Страница 4 из 29

1.3. Обзор

В этом подразделе представлен обзор основных путей использования операции Sync для поддержания синхронизированной клиентской копии фрагмента DIT.

  • Запрос (опрос) изменений: режим refreshOnly.

  • Ожидание посылок изменений: режим refreshAndPersist.

1.3.1. Запрос (опрос) изменений (refreshOnly)

Для получения своей первоначальной клиентской копии клиент выполняет запрос Sync: поисковый запрос с элементом управления Sync Request Control, режим которого задан как refreshOnly. Сервер, также, как это происходит при нормальной операции поиска, возвращает (после контроля доступа и проверок по другим ограничениям) содержимое, удовлетворяющее критериям поиска (база поиска, диапазон, фильтр, атрибуты). Кроме того, с каждой возвращаемой записью сервер предоставляет элемент управления Sync State Control, в котором указано состояние add (необходимость добавить запись). Этот элемент управления содержит универсальный уникальный идентификатор (Universally Unique Identifier, UUID) [UUID] записи [RFC4530]. В отличие от уникального имени (Distinguished Name, DN), которое может со временем меняться, UUID записи неизменен. За первоначальным содержимым следует сообщение SearchResultDone Message с элементом управления Sync Done Control. В элементе управления Sync Done Control имеется синхронизационное куки syncCookie, в котором представлено состояние сессии.

Чтобы запросить изменения для своей клиентской копии, клиент снова выполняет операцию Sync с возвращённым в предыдущий раз syncCookie. Сервер, также, как это происходит при нормальной операции поиска, определяет, какое содержимое должно быть возвращено в том случае, если бы это была нормальная операция поиска. Однако, используя syncCookie как индикатор того, какое содержимое было отправлено клиенту в прошлый раз, сервер посылает копии изменившихся записей с элементом управления Sync State Control, в котором указано состояние add. Для каждой изменённой записи отправляются все принадлежащие содержимому каталога атрибуты (изменённые и неизменённые).

Сервер может выполнить какую-либо из двух или сразу обе различные синхронизационные фазы, отличающиеся друг от друга тем, каким образом синхронизируются удалённые из содержимого каталога записи: фаза наличия (present phase) и фаза удаления (delete phase). Если сервер на стадии обновления использует только одну фазу, она помечается как окончательная посылкой сообщения SearchResultDone Message с элементом управления Sync Done Control. Фаза наличия идентифицируется путём установки в элементе управления Sync Done Control значения refreshDeletes в FALSE. Фаза удаления идентифицируется установкой значения refreshDeletes в TRUE. За фазой наличия может следовать фаза удаления. Эти две фазы отделяются друг от друга сообщением refreshPresent Sync Info Message, у которого значение refreshDone установлено в FALSE. В случае, когда используются обе фазы, фаза наличия применяется для приведения клиентской копии в состояние, с которого может начаться последующая фаза удаления.

Страница 4 из 29

2007 - 2022 © Русские переводы RFC, IETF, ISOC.