Протокол определения местоположения службы

Протокол определения местоположения службы ( SLP , srvloc ) — это протокол обнаружения служб , который позволяет компьютерам и другим устройствам находить службы в локальной сети без предварительной настройки. SLP был разработан для масштабирования от небольших неуправляемых сетей до крупных корпоративных сетей. Он определен в RFC 2608 и RFC 3224 как документ отслеживания стандартов .

Обзор

SLP используется устройствами для объявления услуг в локальной сети. Каждая служба должна иметь URL-адрес , который используется для поиска службы. Кроме того, он может иметь неограниченное количество пар имя/значение, называемых атрибутами . Каждое устройство всегда должно находиться в одной или нескольких областях . Области действия представляют собой простые строки и используются для группировки сервисов, аналогично сетевому окружению в других системах. Устройство не может видеть службы, находящиеся в разных областях.

URL-адрес принтера может выглядеть так:

service:printer:lpr://myprinter/myqueue

Этот URL-адрес описывает очередь под названием «myqueue» на принтере с именем хоста «myprinter». Протокол, используемый принтером, — LPR . Обратите внимание, что принтер использует специальную схему URL-адресов «service:». URL-адреса «service:» не требуются: можно использовать любую схему URL-адресов, но они позволяют искать все службы одного типа (например, все принтеры) независимо от протокола, который они используют. Первые три компонента типа URL-адреса «service:» («service:printer:lpr») также называются типом службы . Первые два компонента («сервис:принтер») называются абстрактным типом сервиса . В URL-адресе, отличном от «service:», именем схемы является тип службы (например, «http» в « http://www.wikipedia.org »).

Атрибуты принтера могут выглядеть так:

(printer-name=Hugo),
(printer-natural-language-configured=en-us),
(printer-location=In my home office),
(printer-document-format-supported=application/postscript),
(printer-color-supported=false),
(printer-compression-supported=deflate, gzip)

В примере используется стандартный синтаксис атрибутов SLP, только для удобства чтения были добавлены только новые строки.

Определение URL-адреса «service:» и разрешенные атрибуты URL-адреса определяются шаблоном службы , формализованным описанием синтаксиса URL-адреса и атрибутов. Шаблоны служб определены в RFC 2609.

SLP позволяет использовать несколько типов запросов для поиска сервисов и получения информации о них:

Он может искать все сервисы с одним и тем же типом сервиса или абстрактным типом сервиса.
Этот запрос можно объединить с запросом атрибутов, используя LDAP . язык запросов
Учитывая его URL-адрес, можно запросить атрибуты службы. В стандартном SLP атрибуты не возвращаются в результате запроса и должны извлекаться отдельно. Расширение списка атрибутов (RFC 3059) устраняет эту проблему.
Список всех видов услуг можно получить
Можно запросить список всех существующих областей действия.

Роли

SLP имеет три разные роли для устройств. Устройство также может выполнять две или все три роли одновременно.

Пользовательские агенты (UA) — это устройства, которые ищут сервисы.
Сервисные агенты (SA) — это устройства, которые анонсируют одну или несколько услуг.
Агенты каталога (DA) — это устройства, которые кэшируют информацию об услугах. Они используются в более крупных сетях для уменьшения объема трафика и обеспечения масштабирования SLP. Существование DA в сети не является обязательным, но если DA присутствует, UA и SA должны использовать его вместо прямого взаимодействия.

Сегодня большинство реализаций представляют собой демоны , которые могут действовать как UA, так и SA. Обычно их также можно настроить на роль DA.

Сетевой протокол

SLP — пакетно-ориентированный протокол. Большинство пакетов передаются с использованием UDP , но TCP также можно использовать для передачи более длинных пакетов. Из-за потенциальной ненадежности UDP SLP повторяет все многоадресные рассылки несколько раз с увеличивающимися интервалами, пока не будет получен ответ. Все устройства должны прослушивать порт 427 для пакетов UDP, SA и DA также должны прослушивать TCP на том же порту. Многоадресная рассылка широко используется SLP, особенно устройствами, которые подключаются к сети и им необходимо найти другие устройства.

Работа SLP существенно различается в зависимости от того, находится ли в сети агент каталога (DA) или нет. Когда клиент впервые присоединяется к сети, он отправляет многоадресный запрос к DA в сети. Если ни один DA не отвечает, предполагается, что он находится в сети без DA. Также возможно добавить DA позже, поскольку они осуществляют многоадресную рассылку «пульсового» пакета через заранее определенный интервал, который будет получен всеми остальными устройствами. Когда SA обнаруживает DA, необходимо зарегистрировать все службы в DA. Когда служба исчезает, SA должен уведомить DA и отменить ее регистрацию.

Чтобы отправить запрос в сети без DA, UA отправляет многоадресный UDP-пакет, содержащий запрос. Все SA, содержащие совпадения, отправят UDP-ответ UA. Если ответ слишком велик, чтобы уместиться в один пакет UDP, пакет будет помечен как «переполненный», и UA сможет отправить запрос непосредственно в SA, используя TCP, который может передавать пакеты любого размера.

Чтобы отправить запрос в сети с DA, UA отправит пакет запроса в DA, используя либо UDP, либо TCP. Поскольку каждый SA должен зарегистрировать все службы в DA, DA может полностью выполнить запрос и просто отправляет результат обратно в UA.

Безопасность

SLP содержит механизм безопасности, основанный на криптографии с открытым ключом , который позволяет подписывать служебные объявления. На практике используется редко:

Открытые ключи каждого поставщика услуг должны быть установлены на каждом UA. Это требование противоречит первоначальной цели SLP — возможности находить сервисы без предварительной настройки.
Защитить только сервисы недостаточно. URL-адреса служб содержат имена хостов или IP-адреса, а в локальной сети практически невозможно предотвратить подмену IP-адреса или DNS . Таким образом, только гарантии подлинности URL-адреса недостаточно, если какое-либо устройство может ответить на адрес.
Поскольку адреса могут быть подделаны, подлинность устройства в любом случае должна быть подтверждена на другом уровне, например, в протоколе приложения (например, с помощью SSL ) или на пакетном уровне ( IPsec ). Выполнение этого дополнительно в SLP не обеспечивает особой дополнительной безопасности.

Принятие

SLP часто используется для поиска принтеров и поддерживается такими системами печати, как CUPS .
SLP часто встречается в принтерах с поддержкой локальной сети, поэтому их можно обнаружить сразу после установки. Некоторые клиентские драйверы печати могут использовать это для обнаружения принтера.
ACN , протокол, разрабатываемый для управления развлечениями, использует SLP для поиска различных устройств, таких как диммеры и интеллектуальные светильники.
Классическая Mac OS и Mac OS X до версии 10.1 использовали SLP для поиска общих файловых ресурсов и других служб. Однако функции, представленные в Mac OS X (версия 10.2 и выше), используют Zeroconf .
Клиенты Netware Core Protocol (NCP) в чисто IP-среде используют SLP для обнаружения серверов Novell NetWare и Novell Open Enterprise Server (OES).
SUSE Linux поддерживает SLP для различных сервисов, начиная с версии 9.1.
Sun Microsystems поддерживает SLPv1 и SLPv2, включая функции SA, UA и DA. ^[1]
Рабочая группа по распределенному управлению стандартизировала обнаружение сервисов WBEM через SLP.
Ассоциация индустрии сетей хранения данных обязала использовать SLP для обнаружения сервисов в Инициативе по управлению хранилищем - Спецификация .

См. также

Ссылки

^ Руководство по администрированию протокола определения местоположения служб (PDF) , Sun Microsystems, февраль 2000 г. , получено 19 августа 2010 г.

Сильвия Хаген , Руководство по протоколу определения местоположения службы , Podbooks.Com LLC, ISBN 1-893939-35-9
Джеймс Кемпф , Роберт Сен-Пьер , Пит Сен-Пьер : Протокол определения местоположения сервисов для корпоративных сетей: реализация и развертывание средства динамического поиска сервисов , John Wiley & Sons, ISBN 0-471-31587-7
Голден Г. Ричард : Обнаружение сервисов и устройств: протоколы и программирование , McGraw-Hill Professional, ISBN 0-07-137959-2
Йохан Хьельм : Создание служб определения местоположения для беспроводной сети , John Wiley & Sons, ISBN 0-471-40261-3
Анна Хак : Протоколы мобильной связи для сетей передачи данных , John Wiley & Sons, ISBN 0-470-85056-6

Внешние ссылки

Модуль LiveTribe SLP/OSGi
Проект протокола местоположения службы
Улучшения протокола определения местоположения службы
OpenSLP
jSLP — чистая реализация Java SLP.
Клиент SBLIM CIM для Java — включает реализацию SLP на Java, совместимую с RFC 2614.
Сравнение протоколов обнаружения сервисов и реализация протокола определения местоположения сервисов
https://web.archive.org/web/20050312060250/http://www.ietf.org/html.charters/svrloc-charter.html — рабочая группа IETF SRVLOC , создавшая стандарт SLP.
Обнаружение WBEM с использованием SLP от DMTF
Шаблон WBEM SLP от DMTF
Автоматизация управления клиентами с помощью протокола определения местоположения службы, статья М. Тима Джонса на сайте DeveloperWorks.

[1] Руководство по администрированию протокола определения местоположения служб (PDF) , Sun Microsystems, февраль 2000 г. , получено 19 августа 2010 г.

[1]