|
The service discovery protocol (SDP) provides a means for
applications to discover which services are available and to determine the
characteristics of those available services.
A specific Service Discovery protocol is needed in the
Bluetooth environment, as the set of services that are available changes
dynamically based on the RF proximity of devices in motion, qualitatively
different from service discovery in traditional network-based environments.
The service discovery protocol defined in the Bluetooth specification is
intended to address the unique characteristics of the Bluetooth environment.
For more details : Download the SDP
Specification from the SIG website, or visit the Documents
Page.
SDP is a simple
protocol with minimal requirements on the underlying transport. It can
function over a reliable packet transport (or even unreliable, if the client
implements timeouts and repeats requests as necessary). SDP uses a
request/response model where each transaction consists of one request
protocol data unit (PDU) and one response PDU. However, the requests may
potentially be pipelined and responses may potentially be returned out of
order.
SDP uses a request/response model where each
transaction consists of one request protocol data unit (PDU) and one response
PDU. In the case where SDP is used with the Bluetooth L2CAP transport
protocol, only one SDP request PDU per connection to a given SDP server may
be outstanding at a given instant. In other words, a client must receive a
response to each request before issuing another request on the same L2CAP
connection. Limiting SDP to sending one unacknowledged request PDU provides a
simple form of flow control.
*Diagram Source: Courtesy of Bluetooth SIG, SDP Specs, Fig
2.1 , p 330
Every SDP PDU
consists of a PDU header followed by PDU-specific parameters. The header
contains three fields:
- PDU ID field identifies the type of PDU. I.e. its meaning and the
specific parameters.
- TransactionID field uniquely identifies request PDUs and is used
to match response PDUs to request PDUs.
- ParameterLength field specifies the length (in bytes) of all
parameters contained in the PDU.
Parameters may include a continuation state
parameter, described below; PDU-specific parameters for each PDU type are
described later in separate PDU descriptions.
Some SDP requests may require responses that are larger than
can fit in a single response PDU. In this case, the SDP server will generate
a partial response along with a continuation state parameter. The
continuation state parameter can be supplied by the client in a subsequent
request to retrieve the next portion of the complete response.
Each transaction consists of a request and a response
PDU. Generally, each type of request PDU has a corresponding type of response
PDU. However, if the server determines that a request is improperly formatted
or for any reason the server cannot respond with the appropriate PDU type, it
will respond with an error PDU (SDP_ErrorResponse) .
The following section describe how the
individual characteristics (services) of the different devices are
stored.
A service is any
entity that can provide information, perform an action, or control a resource
on behalf of another entity. A service may be implemented as software,
hardware, or a combination of hardware and software. All of the information
about a service that is maintained by an SDP server is contained within a
single service record. The
service record consists entirely of a list of service attributes.
Each service
attribute describes a single characteristic of a service. Some examples
of service attributes are ServiceClassIDList & ProviderName
. Some attribute definitions are common to all service records , but service
providers can also define their own service attributes.
A service attribute consists of two components: an attribute ID and an
attribute value.
- An attribute ID is a 16-bit unsigned integer that distinguishes
each service attribute from other service attributes within a service
record. The attribute ID also identifies the semantics of the associated
attribute value.
- The attribute value is a variable length field whose meaning is
determined by the attribute ID associated with it and by the service class
of the service record in which the attribute is contained. In the Service
Discovery Protocol, an attribute value is represented as a data element.
See the section 'Data Representation' below for more information.
Each service is an instance of a service
class. The service class definition provides the definitions of all
attributes contained in service records that represent instances of that
class. Each attribute definition specifies the numeric value of the attribute
ID, the intended use of the attribute value, and the format of the attribute
value. A service record contains attributes that are specific to a service
class as well as universal attributes that are common to all services.
Each service class is assigned a unique identifier
,this service class identifier is contained in the attribute value for the
ServiceClassIDList attribute, and is represented as a UUID. A UUID
is a universally unique identifier that is guaranteed to be unique across all
space and all time. UUIDs can be independently created in a distributed
fashion. No central registry of assigned UUIDs is required. A UUID is a
128-bit value.
The whole point of the SDP is to allow
bluetooth devices to discover what other bluetooth devices can offer (what services).
SDP allows this in various means. Searching means looking for specific
service, while Browsing means looking to see what services are
actually being offered.
The Service Search transaction allows a client to
retrieve the service record handles for particular service records based on
the values of attributes contained within those service records.
The capability search for service records based on the
values of arbitrary attributes is not provided. Rather, the capability is
provided to search only for attributes whose values are Universally Unique
Identifiers (UUIDs). Important attributes of services that can be used to
search for a service are represented as UUIDs. Service search pattern are
used to locate the desired service. A service search pattern is a list of
UUIDs (service attributes) used to locate matching service records.
This process of looking for any offered services is
termed browsing. In SDP, the mechanism for browsing for services is based on
an attribute shared by all service classes. This attribute is called the BrowseGroupList
attribute. The value of this attribute contains a list of UUIDs. Each UUID
represents a browse group with which a service may be associated for the
purpose of browsing.
When a client desires to browse an SDP server’s
services, it creates a service search pattern containing the UUID that
represents the root browse group. All services that may be browsed at the top
level are made members of the root browse group by having the root browse
group’s UUID as a value within the BrowseGroupList attribute.
As mentioned above, In the Service
Discovery Protocol, an attribute value is represented as a data element. A
data element is a typed data representation. It consists of two fields: a
header field and a data field.
The header field is composed of 2 parts, a Type Descriptor and a Size
Descriptor.
- Type Descriptor: A data element type is represented as a 5-bit
type descriptor. The type descriptor is contained in the most significant
(high-order) 5 bits of the first byte of the data element header.
- Size Descriptor: The data element size descriptor is represented
as a 3-bit size index followed by 0, 8, 16, or 32 bits. The size index is
contained in the least significant (low-order) 3 bits of the first byte of
the data element header.
The data is a sequence of bytes whose length is specified in
the size descriptor and whose meaning is (partially) specified by the type
descriptor.
As computing continues to move to a network-centric
model, finding and making use of services that may be available in the
network becomes increasingly important. Services can include common ones such
as printing, paging, FAX-ing, and so on, as well as various kinds of
information access such as telecon-ferencing, network bridges and access
points, eCommerce facilities, and so on — most any kind of service that a
server or service provider might offer. In addition to the need for a
standard way of discovering available services, there are other
considerations: getting access to the services (finding and obtaining the
protocols, access methods, "drivers" and other code necessary to
utilize the service), controlling access to the services, advertising the
services, choos-ing among competing services, billing for services, and so
on. This problem is widely recognized; many companies, standards bodies and
consortia are addressing it at various levels in various ways. Service
Location Protocol (SLP), JiniTM, and Salutation TM, to
name just a few, all address some aspect of service discovery.
The Bluetooth Service Discovery Protocol (SDP)
addresses service discovery spe-cifically for the Bluetooth environment. It
is optimized for the highly dynamic nature of Bluetooth communications. SDP
focuses primarily on discovering services available from or through Bluetooth
devices. SDP does not define methods for accessing services; once services
are discovered with SDP, they can be accessed in various ways, depending upon
the service. This might include the use of other service discovery and access
mechanisms such as those mentioned above; SDP provides a means for other
protocols to be used along with SDP in those environments where this can be
beneficial. While SDP can coexist with other service discovery protocols, it
does not require them. In Bluetooth environments, services can be discovered
using SDP and can be accessed using other protocols defined by Bluetooth.
Note , the above text contains excerpts from the Bluetooth SIG's
Specification, as well as various interpretations of the Specs. For complete
details of the various sections, consult the actual Bluetooth Specification.
|
