Bluez D-Bus Architecture

The BlueZ D-Bus interfaces aim to provide seamless Bluetooth technology integration into the desktop. A central Bluetooth daemon "hcid"(planned to be renamed to bluetoothd) is responsible for take care of all tasks that can’t or shouldn’t be handled inside the Linux kernel. These jobs include PIN code and link key management for the authentication and encryption, caching of device names and services and also central control of the Bluetooth hardware. The interface exported allows to abstract the internals of GNOME, KDE, Maemo, OpenMoko, ... applications from any technical details of the Bluetooth specification. Even other application will get access to the Bluetooth technology without any hassle.   The BlueZ D-Bus services are exported through the system message bus. Every D-Bus enabled desktop has a system message bus instance running. This bus is used to broadcast system events, such as new hardware devices, network connection status, and so forth. The session message bus is not suitable for this architecture since the Bluetooth hardware/connections are shared by all desktop sessions. The BlueZ D-Bus Architecture goal are: Abstract Bluetooth HCI commands/events Provide an easy interface to setup Bluetooth adapter and manage the services Architecture The hcid is the main entity of the architecture. It implements methods to setup the Bluetooth adapters, retrieve remote device properties, control the pairing procedure and control the services registration/searches. The following figure shows a high level relationship between the entities. 1. Adapter Interface The "Adapter" interface provides methods to setup the local adapter(s), search remote devices, pairing and search for services. 2. Manager Interface This interface provides methods to list the available adapters, retrieve the default local adapter path and list/activate services. There is just one Manager object instance provided in the path "/org/bluez". 3. Security Interface .An application that wants to handle passkey requests must use the "hcid" security interface to register a passkey agent. Architecture Step 1: Represents the passkey agent registration Step 2: Represents a client calling CreateBonding Step 3: Represents the hcid asking for a passkey value createBonding->linked key store->send D-BUS Message to register passkey agent ->ask for a passkey HCI event : PIN Request Step 1: Represents the D-Bus message sent to register the default/device specific passkey agent. Step 2: Represents the HCI "PIN Request" event sent by the Bluetooth Host Controller. Step 3: Represents the D-Bus message sent to the default/device speficic passkey agent requesting a passkey. Step 4: Represents the "Auth Complete" event where the status contains "LMP Response Timeout"(The remote didn't type the passkey). Step 5: Represents the "hcid" issuing a "Cancel" to a previous Request call. Step 6: Represents the D-Bus message sent to release the passkey agent: basically sent when the hcid exits. 4. Database Interface SDP queries involves transactions between an SDP server and an SDP client. The server maintains a list of service records that describe the characteristics of services associated with the server. The database interface provides methods to manage local service records(SDP Server). All of the information about a service that is maintained by an SDP server is contained within a single service record. A service record is basically a list of service attributes. Each service attribute describes a single characteristic of a service such as the service type, name, description, ... This section is applied for record registered by D-Bus methods only. Only the record owner can update or remove the record If the owner exits, the record is automatically removed from the database 5. Service Interface The service interfaces aim provide an easy way to develop Bluetooth services. For remote service search(handles/records) check the Adapter interface. This section is restricted to local interactions only. There are two interfaces related to Bluetooth services: Service interface: retrieve information about the registered service. eg: name, description, status, Bus id, ... Database interface: manage SDP records and service connection authorizations BlueZ services can be classified as external and internal. Internal are services registered automatically when the system starts. External are services running in the standalone mode where the user start the service and ask for registration. Once the service is registered, an object instance will be available 6.Bluetooth Audio There have been many attempts at implementing different audio profiles for BlueZ. The current approach is to implement an audio service which fits into the new D-Bus based service framework and which implements all of the profiles in a flexible enough way to be usable by everyone. To minimize audio data copying in memory and to acheive as low latency as possible, the audio service is not responsible for transmitting the actual audio but passes the audio stream socket descriptor to an ALSA plugin which will in turn be responsible for enconding/decoding and sending/receiving of the audio data. Some things to work on System-wide audio device (mixing for multiple simultaneous access) For combo sets, choose voice or hifi low in driver (based on client requirements) Changing from wired to wireless audio mid stream (probably needs something like pulse) 7. Bluetooth Input The Bluetooth Input daemon provides an interface to access Bluetooth Human Interface Devices. The Manager interface provides methods to list, create and remove input devices objects. The Device interface provides methods to retrieve device information, connect and disconnect. Currently, fake input devices and device initiated connections are not supported. The input service can be initiated even if there isn't an adapter available. Obviously new input objects can't be created since an adapter is required to perform service handle/record search. Input Objects (1) Represents a host initiated connection. Where a previously created input object is used to connect to a HID compliant device. (2) Represents a remote initiated connection. 8.Bluetooth Network Service The Bluetooth network service provides an interface to setup Bluetooth Personal Area Networks (PAN) that support common networking protocols such as IPv4, IPv6, IPX, and other existing or emerging networking protocols. Completely un-modified Ethernet payloads can be transmitted using the Bluetooth Network Encapsulation Protocol (BNEP) to exchange packets between Bluetooth devices. 9.Bluetooth Serial Service The serial service, introduced in the BlueZ 3.10, provides a convenient way for setting up emulated serial cable connections using RFCOMM between two peer devices. Methods and signals tagged as "experimental" are not available yet. They may be available soon when clear requirements has been defined.

原文地址 http://wiki.bluez.org/wiki/Architecture