meta data for this page

=Device database entries= Device database is a storage area located in Daemon. Daemon stores into this storage the information concerning the found devices (and their services).

'DeviceStorage' has the following elements(most important fields)

std::list<CDaemonDevice *> iDevicelist

Each element in this list is of AbstractDevices of types, BaseDevice, DaemonDevice or LibDevice.

'DaemonDevice' has the following parameters:

std::string iName

std::string iAddress

std::string iPrototype

std::list<Cservice *> iServiceList

bool iHasPeerHood

int i iTimeStamp

and few other not so important parameters (referrername and checksum). At least I think so at the moment.

=Use of device database=

Instantiating database

Device database is intantieted in Daemon() with the command CDeviceStorage:.GetInstance(). This approach follows the Singleton pattern and thus makes it sure that only one instance of storage is always in use.

Filling up the database

Device database is filled by the different communication Plugins with their Plugin.Start() functions. Plugin.Start executes the inquiry thread that looks for other devices (according to the methods of each technology.

Plugin.Advert() function answers to the inquiries of each Plugin.

Use of the database

From applications on the same device

Applications may use the device database by using the GetDeviceList(service) method. This call returns a list of devices in the daemon's database at that moment.

GetDeviceList() initiates the following communication sequence:

Library sends PH_GET_DEVICE_LIST pdu to the deamon. Daemon answeres by sending 1) the number of devices in database, 2) length of each device+its services and finally 3) the device information. The received devices are returned to the application. If service is defined in the call then only those devices that have the service are returned.

From other devices

One of the key features of PeerHood approach is the property of finding new devices and services within them. While new devices are observed, the inquiry thread …

When receiving a service inquiry, the Advert thread …