ACAP (Application Configuration Access Protocol)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 20:15, 5 января 2018.
ACAP
Communications protocol
Purpose Удалённое хранение конфигурационных данных
Based on IMAP4
Port(s) 674/TCP
RFC(s) RFC 2244

ACAP (англ. Application Configuration Access Protocol) - сетевой протокол, позволяющий пользователю иметь доступ к конфигурационным данным приложений, поддерживающих ACAP, с любого компьютера, подключенного к сети. Протокол основан на IMAP4. [Источник 1]

Были проведены две Международные конференции АСАР, одна в Питтсбурге, штат Пенсильвания, США, в 1997 году, а другая в Qualcomm Incorporated, в Сан-Диего, Калифорния, США, в феврале 1998 года.

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

В отличие от LDAP, ACAP был разработан для частой записи, отключенного режима доступа (то есть клиенты могут перейти в автономный режим, а затем повторно синхронизировать позже), и так далее. Он также обрабатывает наследование данных, иногда известное как стекирование, что обеспечивает легкое создание значений по умолчанию. [Источник 2]

Структура протокола

Уровень соединения

Протокол ACAP предполагает надежный поток данных, такой как протокол TCP. Когда используется протокол TCP, сервер ACAP подчиняется порту 674.

Команды и отклики

Сеанс ACAP состоит из установления подключения клиента/сервера, начального приветствия от сервера и взаимодействия клиента/сервера. Эти взаимодействия клиента и сервера состоят из команды клиента, данных сервера и результата завершения сервера.

АСАР - это текстовый однострочный протокол. В общем, взаимодействие происходит посредством передачи клиентов и серверов в виде линий; то есть, последовательности символов, которые заканчиваются с CRLF. Приемник протокола клиента или сервера ACAP либо считывает строку, либо считывает последовательность октетов с известным количеством (литералом), за которым следует строка. И клиенты, и серверы должны быть способны обрабатывать линии произвольной длины.

Отправка клиентских протоколов и приемник серверных протоколов

Команда клиента начинается с операции. Каждая команда клиента содержит идентификатор (буквенно-цифровая строка не более 32 символов, например, A0001, A0002 и т. д.), который называется "тег". Для каждой команды клиент должен создать отдельный тег. Существует два случая, когда строка клиента не представляет собой полную команду. В одном случае аргумент команды цитируется со счетчиком октетов; в другом случае аргумент команды требует обратной связи с сервером. В некоторых случаях сервер отправляет запрос на продолжение команды, если он готов к следующей части команды. Этот ответ начинается со знака "+".

Кроме того, сервер может отправлять завершенный или промежуточный ответ для какой-либо другой команды (если выполняется несколько команд) или не помеченных данных.

Сервер ACAP считывает командную строку из клиента, анализирует команду и ее аргументы и передает данные сервера и результат выполнения команды.

Отправка протокола сервера и приемник протокола клиента

Данные, передаваемые сервером клиенту, поступают в четырех формах:

  1. запросы на продолжение команды
  2. результаты выполнения команды
  3. промежуточные ответы
  4. ответы без тегов

Запрос на продолжение команды имеет префикс "+".

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

  • ОК (успешная)
  • NO (признак ошибки),
  • BAD (с указанием ошибки протокола, таких как нераспознанная команда или команда синтаксическая ошибка).

Не помеченный ответ возвращает данные или сообщения о состоянии, которые могут быть интерпретированы вне контекста выполняемой команды - префикс с маркером "*". Не помеченные данные могут быть отправлены в результате команды клиента или отправлены сервером в одностороннем порядке. Синтаксическая разница между не отмеченными данными, полученными в результате выполнения определенной команды, и не отмеченными данными, отправленными в одностороннем порядке, отсутствует.

Приемник протокола клиента ACAP считывает строку ответа с сервера. Затем выполняется действие на основе первого маркера ответа, который может быть тегом "*"или"+".

Клиент должен быть готов принять любой ответ сервера в любое время. Это включает в себя неподписанные данные, которые он, возможно, не запросил.

Форма сервера

Сервер ACAP находится в одном из трех состояний. Большинство команд действительны только в определенных формах. Это ошибка протокола для клиента, который пытается выполнить команду, пока сервер находится в неподходящем состоянии для этой команды. В этом случае сервер ответит результатом BAD на выполнение команды.

Форма без проверки подлинности - перед тем, как большинство команд будут разрешены, пользователь должен предоставить учетные данные для проверки подлинности. Это состояние вводится при запуске подключения.

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

Выход из системы - сессия завершается, и сервер прекращает соединение. Это состояние может быть введено в результате запроса клиента или одностороннего решения сервера. [Источник 3]

Записи и атрибуты

В наборе данных имя каждой записи состоит из нуля или более записей UTF-8 символов, по одной на каждом уровне иерархии, формирует полный путь к записи.

Каждая запись состоит из набора атрибутов. Каждый атрибут имеет иерархическое имя в UTF-8, с каждым компонентом имени, разделенным точкой (".").

Значений атрибута может быть одно или несколько. Одно значение-NIL (не имеет значения) или строка нулевого или более октетов. Многозначный список - это список нулевых или более строк, каждая из которых содержит ноль или более октетов.

Имена атрибутов не могут содержать звездочку ("*") или процент ("%") и должны быть допустимыми строками UTF-8, которые не содержат NUL. Недопустимые имена атрибутов приводят к неправильному ответу. Имена записей не разрешены для начала "." или содержат косую черту (" / " ) и должны быть допустимыми строками UTF-8, которые не содержат NUL. Недопустимые имена записей в поле ввода команды приводят к неправильному ответу.

Использование невидимых символов UTF-8 в именах атрибутов и записей не рекомендуется.

Предустановленные атрибуты

Имена атрибутов, которые не содержат точки (".") зарезервированы для стандартных атрибутов, имеющих значение в любом наборе данных. Следующие атрибуты определяются протоколом ACAP:

Entry - содержит имя для входа. Попытки использования противозаконных или многозначных значений атрибутов для входа ведут к ошибке протокола и ведет к ответу BAD. Это особый случай.

Modtime - cодержит дату и время последнего изменения метаданных чтения-записи в записи. Это значение должно быть в формате UTC, должно быть автоматически обновлено сервером. Значение состоит из 14 или более цифр US-ASCII. Первые четыре указывают на год, следующие два указывают на месяц, далее на день месяца, час (0 - 23), минуту, секунду. Любые дополнительные цифры указывают на долю секунды. Время, особенно доли секунды, не должно быть точным. Однако необходимо, чтобы любые две записи в наборе данных, измененные последовательными изменениями, имели строго возрастающие значения modtime. Кроме того, каждая команда в наборе данных должна использовать различные значения modtime. Этот атрибут имеет принудительную проверку, поэтому любая попытка сохранить значение в этом атрибуте может привести к отсутствию ответа с недопустимым кодом ответа.

Subdataset - значение состоит из списка относительных URL-адресов ACAP, которые могут быть использованы для обнаружения подмножества данных. Базовый URL-полный путь к записи косой черты ("/"). Значение"." указывает, что подмножество находится прямо под ним. Несколько значений указывают на реплицированные копии набора вложенных данных. Набор данных может быть создан путем сохранения атрибута "поднабора" в том числе ".", и суб-иерархии наборов данных удаляется, сохраняя нулевое значение атрибута "поднабора" на запись в родительский набор данных. Этот атрибут имеет принудительную проверку синтаксиса.

Атрибут метаданных

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

В этой спецификации определены следующие элементы метаданных:

ACL - список управления доступом для атрибута, если он существует. Если атрибут не имеет списка управления доступом, возвращается NIL. Чтение-запись.

Attribute - имя атрибута. Только для чтения.

Myrights - набор прав, которые клиент имеет к атрибуту. Только для чтения.

Size - это длина значения. В случае многозначности это список длин для каждого из значений. Только для чтения.

Value - значение. Для многозначных значений это список отдельных значений. Чтение-запись.

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

Схема URL

URL ACAP имеет формат: acap:// url-server / url-enc-entry [url-filter] [url-extension]

  1. url-server — элемент включает имя хоста и необязательное имя пользователя, механизм проверки подлинности и номер порта. В <url-enc-entry> элемент содержится название пути записи, закодированного в соответствии с правилами в базовом URL-адресе;
  2. url-enc-entry — имя узла;
  3. url-filter — элемент - необязательно список содержащихся имен атрибутов. Если этот параметр не указан, URL-адрес ссылается на все атрибуты именованной записи. В <url-extension> элемент зарезервирован для расширений для этой схемы URL;
  4. url-extension — зарезервировано для будущих расширений. [Источник 4]

Источники

  1. Application Configuration Access Protocol// Википедия [2017—2017]. URL:https://ru.wikipedia.org/wiki/Application_Configuration_Access_Protocol (дата обращения: 11.11.2017).
  2. Application Configuration Access Protocol// Wikipedia [2017—2017]. URL:https://en.wikipedia.org/wiki/Application_Configuration_Access_Protocol (дата обращения: 11.11.2017).
  3. ACAP -- Application Configuration Access Protocol// TOOLS.IETF [2017—2017]. URL:https://tools.ietf.org/html/rfc2244 (дата обращения: 11.11.2017).
  4. ACAP -- Application Configuration Access Protocol// FAQS [2017—2017]. URL:http://www.faqs.org/rfcs/rfc2244.html(дата обращения: 06.12.2017).
.