Hardware Reference
In-Depth Information
(through a firmware update or perhaps with the installation of applications on the server
device, for example). Certain rules and constraints are therefore required, so that a client
can rely on the validity of previously discovered handles without risk of them having
changed on the server and thus no longer being valid.
As a general rule, the specification recommends that clients cache (i.e., store for sub‐
sequent transactions and even connections) the handles of the attributes they are in‐
terested in. Attribute values, especially in the cases where they correspond to actual user
data, are highly volatile, so it usually makes little sense to store them locally in the client
for future use.
The specification provides the Service Changed characteristic (discussed in more detail
in
“GATT Service” on page 73
) for servers to communicate to the client any potential
changes in the contents of its attribute information. This is an optional characteristic,
so its mere presence on the server already acts as an alert regarding the actual possibility
of structural attribute changes.
Clients can ascertain if the result of discovery can be cached for future use by observing
the following conditions:
No Service Changed characteristic present on the server
Clients can freely and permamently cache all handles found with no restrictions.
The server guarantees they will not change during the lifetime of the device.
Service Changed characteristic present on the server
In this case, a client needs to subscribe to the server-initiated updates by writing
into the corresponding CCCD enclosed within the Service Changed characteristic
(see
“Characteristic Descriptors” on page 61
). This will allow the server to alert the
client of any structural changes. If the client and the server are bonded as described
in
“Security Modes and Procedures” on page 46
, the client can cache attribute han‐
dles across connections and expect them to remain identical. If the devices are not
bonded, the client will need to perform discovery every time it reconnects to the
server.
“GATT Service” on page 73
provides more details about using the Service Changed
characteristic.
GATT Attribute Data in Advertising Packets
Although GATT primarily relies on established connections between a central and a
peripheral (as described in
“Roles” on page 36
), it is also possible to include portions of
the attribute information hosted by the server inside advertising packets, rendering one
or more server attributes available to any observer or central while scanning.
Table 3-3
discusses the Service Data AD Type, but that section does not describe the
format it uses to enclose server attributes inside an advertising packet. The Core
