meta data for this page
The goal of the PeerHood system is to provide a communication environment where devices are aware of their surroundings. In order to enable fast creation of required ad-hoc type networks the immediate neighbors of a device are monitored and the gathered information is stored for possible future usage. This is implemented through Daemon functionality.
The second goal is to create a library that enables usage of any supported networking technology via a unified interface so that the underlying networking structure is hidden from the applications point of view. As a direct consequence the application development time should be reduced because complex tasks like device discovery, connection establishment and error checking are handled by the PeerHood system.
The third goal is to offer seamless connectivity. Whenever some service is used through one networking technology and this technology gets out of range, it should be seamlessly be possible to swicth into some other technology the device where the service is offers.
PeerHood provides a common interface to underlying network technologies for PeerHood enabled applications. Other PeerHood devices are presented to applications similarly, regardless of the underlying network technology. Currently, Bluetooth, WLAN and GPRS support has been implemented in Linux version of PeerHood. Several functions, which are common to many applications, are designed as Middleware modules. These functions can be used with the common PeerHood interface, and therefore it's not necessary to implement all of them in applications. Currently designed middleware modules include
Every PeerHood system must implement the following functionality:
• Device discovery – Peerhood must be able to detect other PeerHood-cabaple devices that are within the range and belong to the same neighborhood. How the device detection is done, depends on the underlying networking technology and is left as an implementation specific issue.
• Service discovery – PeerHood must be able to detect what services are available on a remote device and what attributes they contain. How the service information is transferred between the devices is implementation specific as long as the proper packet structure and message flow are followed.
• Service sharing – PeerHood has to offer a mechanism for applications or additional middleware components to use and register services. PeerHood advertises the available services to other devices using networking technology dependent mechanisms.
• Connection establishment – PeerHood must offer a way to connect two or more devices in the same PeerHood neighborhood. The connection procedure must be transparent so that from upper layer’s point of view the underlying networking technology doesn’t affect the procedure. The only exception is that technologies that on the hardware level allow only one connection at a time are not required to support multiple simultaneous connections. PeerHood should offer a streaming socket interface to handle the established connection providing MAbstractConnection interface.
• Data transmission between devices – PeerHood must support data transmission between connected devices via objects that implement the MAbstactConnection interface. The programmer is in charge to ensure that endianess and word length issues are handled in a proper way. In other words, the PeerHood should not care about the content of the transferred data.
• Active monitoring of a device – It must be possible to put some device in the PeerHood neighborhood under active monitoring. This means that a requesting application or middleware component is notified as soon as the monitored device goes out or comes to the range. Proper response time and range are technology dependent issues.
• Provide Seamless Connectivity – Seamless Connectivity defines a technology for changing the active networking technology automatically if the established connection weakens or breaks. Seamless Connectivity tries to always provide the best possible connection for the user while maintaining connectivity. NOTE: This feature is still very experimental and is NOT implemented in Symbian OS version.
This part of the dokumentation explains the elements of PeerHood. Elements are divided into main elements and additional elements. Main elements are the different instansies of PeerHood whereas additional elements support and implement operations needed by the main elements.
Daemon is the element that scans the neighborhood. Daemon is run on the background and it uses network plugins and their implementations to scan the environment. Whenever daemon sees a new device, it queries the wanted information from that device. This information may include device specific info, e.g. device name, service specific info, e.g. service name and attributes, plugin specific info, e.g. the supported plugins, neighbor specific info, e.g. neighbors and their services, and much more that is considered important by the daemon of the device. The required info is defined in the .phconfig file. .phconfig file contains also settings for the activity of the daemon, e.g. interval for inquiries.
Daemon stores information gathered from the neigborhood into DeviceStorage. With different internal algorithms it is possible to use the gathered information in intelligent ways.
Library is the interface to the information gathered by the daemon. Library implmenents functions that are used for requesting information about the neighborhood. The neighborhood consists of both local and remote services known by the daemon. Library offers also functions to register and unregister local services as well as functions for connecting into services (local or remote).
Servers, clients or services are just implementations of local instances that use Library to use the services offered by the PeerHood. Servers are typically offering (multiple) services, whereas clients are merely using these services. Servers with only one service could be called just services.
Device is some instance that can be seen by the daemon. If the device has PeerHood daemon running, then it is PeerHood-enabled device. From these devices extra information can be fethed. Daemon inquiries and finds also devices that are not PeerHood enabled but then no extra information can be fethed.
BaseDevice defines the basis for the devices, while DaemonDevice and LibDevice define devices for the daemon and library.
Service is what PeerHood devices offer to each other. Whenever a server registers a service to the daemon, it can be seen by the other daemons. Service has name, attributes and a port attached.
In order to use services in local and in remote device, a connection is needed.
This part of the manual explains the usage of different elements of PeerHood package with more details. NOTE: One should add UML and MSC diagrams for each one of the descriptions.
Almost finished documentation
service-database - JP: Requires still UML and MSC diagrams. Otherwise quite extensively written document how services are registered etc.