×
Namespaces

Variants
Actions

Bluetooth - обнаружение сервисов

From Nokia Developer Wiki
Jump to: navigation, search
Article Metadata

Статья
Перевод:
Den123
Последнее редактирование: hamishwillee (09 Dec 2011)

Contents

Введение

Протокол обнаружения сервисов (Service Discovery Protocol, SDP) позволяет сетевым устройствам, приложениям, сервисам выполнять поиск удаленных устройств, приложений и сервисов, необходимых для выполнения тех или иных задач. Индустрия сетевых решений постоянно развивается и влючает в себя все новые и новые протоколы обнаружения сервисов. Sun обогащает платформу Java технологией Jini. Microsoft продвигает Universal Plug and Play (UPnP). IETF (Internet Engineering Task Force) поддерживает протокол SLP (Service Location Protocol). Salutation (независимый консорциум ведущих технологических компаний) также предлагает открытый протокол обнаружения сервисов, который уже используется в нескольких продуктах на рынке. В данной статье описывается протокол Bluetooth SDP, который предлагает собственные методы обнаружения сервисов как часть собственного стека протоколов. Кроме того, поддержка Bluetooth предполагает собственную аппаратную реализацию данного протокола.

Протокол обнаружения сервисов (SDP)

SDP определяет последовательность действий, которые должно выполнить клиентское приложение Bluetooth для обнаружения имеющихся сервисов Bluetooth-серверов и получения их характеристик. Протокол определяет, каким образом клиент может выполнить поиск сервисов с заданными характеристиками ничего не зная об их наличии. Протокол позволяет обнаружить доступность новых сервисов, в случае если клиент попадает в зону действия Bluetooth-сервера. Кроме того, SDP предоставляет функциональность, позволяющую определить, когда сервис становится недоступным.

Каждое поле данных SDP PDU (Protocol Data Unit) содержит заголовок, за которым следуют специфические параметры. Заголовок содержит 3 поля:

  • PDU ID - идентификатор типа PDU. Определяет тип и параметры поля (1 байт).
  • TransactionID - идентификатор транзакции. Однозначно идентифицирует поля данных запроса и используется для связывания их с полями ответа (2 байта).
  • ParameterLength - содержит длину (в байтах) всех параметров, содержащихся в PDU (2 байта)

Специфические параметры каждого PDU описываются далее в каждой секции PDU. Параметры могут включать специальный атрибут состояния продолжения - continuation state.Некоторые SDP-запросы могут потребовать больших ответов, которые не поместятся в одно PDU. В этом случае SDP-сервер будет генерировать частичные ответы с атрибутом continuation state. Этот же атрибут может использоваться клиентом при посылке запросов для получения очередной порции ответа. Такой запрос содержит только два поля: InfoLenght (1 байт) и Continuation Information (размером InfoLenght байт).

Каждая транзакция содержит запрос и ответ. Обычно, для каждого типа PDU в запросе, представлен соответствующий тип PDU в ответе. Если сервер определяет, что запрос неправильно сформирован или сервер не может ответить, используя PDU соответствующего типа по каким-либо причинам, то в качестве ответа используется error PDU (SDP_ErrorResponse).

Устройства, поддерживающие SDP имеют следующие характеристики:

Сервисная запись (Service Record)

Сервис - это любая сущность, которая может предоставлять информацию, выполнять действия или контролировать действия от имени другой сущности. Сервис может быть реализован как программно, так и аппаратно либо комбинировано. Вся информация о сервисе, который работает через SDP, содержится в одной сервисной записи (Service Record). Сервисная запись полностью состоит из списка сервисных атрибутов.

Сервисный атрибут (Service Attribute) Каждый атрибут описывает одну характеристику сервиса. SDP имеет следующие сервисные атрибуты:

  • ServiceRecordHandle,
  • ServiceClassIDList,
  • ServiceRecordState,
  • ServiceID,
  • ProtocolDescriptionList,
  • BrowseGroupList,
  • LanguageBaseAttributeIDList,
  • ServiceInfoTimeToLive,
  • ServiceAvaliability,
  • BluetoothProfileDescriptorList,
  • DocumentationURL,
  • ClientExecutibleURL,
  • IconURL,
  • ServiceName,
  • ServiceDescription,
  • ProviderName.

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

Сервисный атрибут состоит из двух компонентов: идентификатора и значения.

  • Идентификатор атрибута (ID) - это целое беззнаковое число (16 бит), которое однозначно определяет данный атрибут среди других атрибутов сервисной записи. Кроме того, идентификатор определяет семантику значения.
  • Значение атрибута (Value) - это поле переменной длины, смысл которого определяется идентификатором атрибута и сервисным классом записи, в которой атрибут содержится. В SDP значение атрибута представлено в качестве элемента данных.

Класс сервиса (Service Class) Каждый сервис является экземпляром класса сервиса. Класс включает в себя определение всех атрибутов, входящих в соответствующую сервисную запись. Определение атрибута включает в себя идентификатор атрибута, его назначение, а также формат, используемый для хранения значения. Сервисная запись может содержать атрибуты, как характерные для данного класса, так и универсальные атрибуты, используемые всеми сервисами.

Каждому сервисному классу присвоен гарантированно уникальный идентификатор - UUID. Значения UUID могут создаваться и присваиваться в свободной форме, никакого централизованного реестра не требуется. UUID - это 128-битное значение, но возможны более короткие псевдонимы (16- или 32-битные), которые можно расширить до стандартного 128-битного представления следующим образом:

128_bit_value = 16_bit_value * 296 + Bluetooth_Base_UUID
128_bit_value = 32_bit_value * 296 + Bluetooth_Base_UUID

Обнаружение сервисов (Service Discovery) Основное назначение SDP - позволить Bluetooth-устройствам обнаружить, какие сервисы предлагают удаленные Bluetooth-устройства. Для этого в SDP предусмотрено несколько способов. Поиск (Searching) подразумевает нахождение конкретных сервисов, в то время как просмотр (Browsing) предполагает обнаружение всех предлагаемых сервисов.

Поиск сервисов (Searching for Services) Транзакция поиска сервисов позволяет клиенту получить дескрипторы (handles) конкретных сервисных записей, исходя из значений атрибутов, содержащихся в этих записях.

Возможность поиска сервисных записей с помощью значений произвольных атрибутов не поддерживается. Важные атрибуты записей хранят значения в виде уникальных идентификаторов (UUID), только такие атрибуты можно использовать для поиска.

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

Просмотр сервисов (Browsing for Services) Browsing for Services предполагает просмотр всех предлагаемых сервисов, для этого в SDP используется атрибут BrowseGroupList, разделяемый между всеми классами сервисов. В качестве значения BrowseGroupList содержит список уникальных идентификаторов. Каждый UUID представляет собой группу просмотра, с которой ассоциируется конкретный сервис. Для просмотра сервисов клиент может использовать шаблон поиска сервисов, содержащий корневой UUID просматриваемой группы. Все сервисы, которые могут быть просмотрены на верхнем уровне, представлены в виде членов корневой группы.

Представление данных Как было сказано выше, в SDP значение атрибута представляется в качестве элемента данных. Элемент данных - это типизированное представление данных. Состоит из двух полей: заголовка и данных.

Заголовочное поле элемента данных Заголовочное поле состоит из двух частей - дескриптора типа (Type Descriptor) и дескриптора размера (Size Descriptor).

  • Дескриптор типа: размером 5 бит, занимает старшие разряды элемента данных.
  • Дескриптор размера: размером 3 бита, занимает младшие разряды первого байта заголовка элемента данных. За ним следует 0, 8, 16 или 32 бита.

Поле данных элемента данных Это последовательность байт, чья длина задана в дескрипторе размера, и чье значение определяется (частично) дескриптором типа.

Организация взаимодействие с использованием SDP

Для организации различных сервисов необходимо обеспечить возможность взаимодействия устройств разных производителей. Такое взаимодействие становится возможным, если устройства поддерживают одинаковые профили. Утверждением новых профилей, а также проверкой изделий производителей на соответствие спецификациям Bluetooth, занимается организация Bluetooth SIG (Bluetooth Special Interest Group). Стек протоколов Bluetooth содержит протокол SDP, который позволяет обнаруживать сервисы, доступные на устройствах (либо с помощью устройств) на небольшом расстоянии от пользовательского устройства. После обнаружения доступных сервисов, пользователь может воспользоваться одним или несколькими из них. Не смотря на то, что SDP не принимает непосредственного участия в определении сервисов, информация, полученная через данный протокол, облегчает этот процесс благодаря тому, что SDP надлежащим образом настраивает Bluetooth-стек для определения требуемых сервисов.

SDP поддерживает следующий набор сервисных запросов:

  • поиск сервисов по сервисному классу
  • поиск сервисов по сервисным атрибутам
  • просмотр сервисов

Перечисленные выше сценарии запросов подразумевают:

  • поиск сервисов на конкретном устройстве, к которому пользователь "осознанно" подключился и/или
  • поиск сервисов на устройствах, обнаруженных поблизости, с которыми пользователь не устанавливал соединения.

Оба перечисленных подхода требуют, чтобы устройство первоначально было обнаружено, далее с ним должно быть выполнено соединение, после чего можно выполнить запрос о наличии поддерживаемых сервисов. Diagram Source.png

Взаимодействующие устройства могут иметь следующие роли:

Локальное устройство (LOCAL device, LocDev). Это устройство, которое инициализирует процедуру обнаружения сервисов. Локальное устройство должно содержать как минимум клиентскую часть архитектуры Bluetooth SDP. Кроме того, такое устройство содержит приложение, которое использует процедуру обнаружения сервисов (SRVDscApp) - данное приложение используется пользователем для инициации процедуры обнаружения и для отображения результатов ее выполнения.

Удаленное устройство(а) ( REMOTE Device(s), RemDev(s) ). Любое устройство, которое участвует в процессе обнаружения сервисов, отвечая на запросы, генерируемые LocDev. RemDev содержит как минимум серверную часть архитектуры Bluetooth SDP. Удаленное устройство содержит базу данных сервисных записей, которая используется при формировании ответа на запросы со стороны локального устройства.

Перед тем, как два любых устройства с поддержкой Bluetooth смогут "общаться" друг с другом требуется:

  • Включить и инициализировать устройства. Инициализация может потребовать ввода PIN для создания ссылочного ключа (link key), используемого для авторизации и шифрования данных.
  • Создать Bluetooth-соединение, для этого может потребоваться BD_ADDR другого устройства, который можно получить с помощью стандартного запроса и пейджинга результатов.

Заключение

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

This page was last modified on 9 December 2011, at 05:04.
104 page views in the last 30 days.

Was this page helpful?

Your feedback about this content is important. Let us know what you think.

 

Thank you!

We appreciate your feedback.

×