Discovery and Peering - universAAL/middleware GitHub Wiki
In order to ensure that communication can take place across all the networked nodes, firstly, nodes must be discovered and enabled to exchange messages. The main function of Discovery & Peering building block is the seamless connectivity between networking-enabled nodes, it is given if nodes, participating in an open distributed system, find each others and connect in a dynamic way. Seamless connectivity is especially appropriate for AmI systems, because they provide an implicit boundary for such automatism, due to being bound to a certain locality. Discovery & Peering building block includes the possibility of using existing / standard protocols as appropriate in the realization of such task. Furthermore, it must be allowed to use a number of protocols for realizing Discovery & Peering in order to be able to extend the range of devices that can be integrated into AAL systems. Without multiple protocols seamless connectivity is effectively given only for groups of nodes that adopt the same protocol and hence forming the so-called "islands of discoverability" [2] where the communication can only be partial. This can be overcome if some of the nodes in the different ensembles support multiple protocols. Such nodes need then a bridging mechanism for turning the fragmented scene with several separated ensembles of nodes into one integrated ensemble.
For the purposes of our scenario it becomes straightforward to distinguish between the discovery phase from the peering phase (D&P):
- Discovery phase: the nodes need to first discover the uSpaces that are present and to select to which uSpace to join. After that, the nodes will be notified about newly registered nodes or nodes that leave the uSpace. The discovery phase will manage both the discovery of the uSpaces and the discovery of the nodes.
- Peering phase: the peers establish a hand-shake session with the node responsible of the uSpace management (also called uSpace Coordinator) in order to exchange relevant information about the system configuration like type of channels to use, security configurations and so on.
This section provides an overview of the discovery mechanisms.
As described in "Discovery Systems in Ubiquitous Computing", discovery is: the process by which an entity on a network (a client) is spontaneously notified of the availability of desirable services or devices on the network (resources) [2]. More generally, discovery task can be characterized from several aspects:
- Topology: discovery systems can be designed in order to exploit one or more servers keeping trace of available resources. This architecture provides higher performance for large networks, and it is usually used in wide area networks (WAN). In a different way, discovery system can be designed with a peer to peer approach, no centralized structures support resource management activities or client searches. This solution is usually adopted in (Wireless) Local Area Networks (LAN) where peers make use of multicast messages.
- Transport: some systems rely on middleware designed for IP network and the clients discover/address IP-resources (e.g. DNS). Other systems rely on non-IP networks (e.g Bluetooth) while other ones adopt out-of-network mechanisms where the discovery tasks are performed by exploiting transport not designed for data communication (RFID, IR beacons).
- Scope: the resource scope represents the set of resources that are discoverable by a given client [2]. The scope affects the number of resources that a client can look for, the network topology and the network configuration can increase/decrease the addressable resources. For example discovery systems based on multicast announce messages have a scope bounded within the LAN where multicast messages are allowed.
- Search: the search task represents one of the pillars for discovery systems. Some systems provide searches only based on resource type or resource name, while other systems extend the search by introducing complex semantic queries for resource discovery. The search strategy impacts the computation that clients and resources need in order to process the client's query.
- Security: discovery systems can be designed without considering any security issue or by introducing security aspects like link-layer encryption, authentication and access control. The security may have a relevant impact on the user experience up to nullify the plug and play mechanism grounded on the service discovery capabilities.
As previously introduced, the notion of resource comprises both devices and services. The service discovery can be considered as a specific case of discovery systems that enables devices and services to properly discover, configure and communicate with each other [1]. No explicit user interactions should be required in order to increase the dynamism and usability of available services. Nowadays exist different enterprise solutions for service discovery (e.g. UPnP, Jini, Bonjour) however such solutions are designed for service discovery in terms of network topology and location and not always feet Pervasive computing challenges. Pervasive computing poses some specific challenges that differ form enterprise solutions:
- Dynamism: pervasive environments operate not only within a specific LAN but interact between heterogeneous networks
- Integration with people: integration of computing device with people introduces new challenges like security, privacy, personal information sharing, context-data integration.
The paper presented in [1] proposes a taxonomy of 10 possible design choices for the definition of service discovery protocols, in order to better organize the discussion and in accordance with the distinction introduced in the Blackbox section, it is convenient to associate a subset of the design choices with the discovery phase, while others with the peering one. Figure below reports a tabular representation of features characterizing service discovery systems.
The black circled items are associated to the Discovery phase:
- Service and attribute naming: Clients can perform searches by adopting a template-based approach to format service names and attributes or clients can use a predefined set of common attributes and service names
- Initial communication method: Clients or services can adopt one of the common methods to perform searches or announce the service availability: unicast, multicast or broadcast
- Discovery and registration: Services can be discovered by announcing their presence to the whole network or by registering into a shared directory.
- Service Discovery Infrastructure: The directory-based architecture exploits servers that keep trace of available services and that processes client queries and announcements. With a nondirectory-based architecture the network only relies on network peers.
- Service Information State: With soft state protocols services announce once, as soon as a client requires for the specific service the client can poll the service again in order to confirm the service availability. With hard state protocols the service periodically announces their presence to the network.
- Discovery Scope: Network topology-based discovery assumes that clients and services are placed in the same administrative domain. User role protocols support administrative domains as discovery scope by enabling users to specify the set of domains where search for services. Discovery protocols can exploit context information in order to enrich the definition of discovery scope, by providing to clients more accurate criteria for service discovery.
This section provides a description of some existing protocols (or protocol stacks) able to answer to the Discovering and Peering challenges. Actually only a subset of the existing discovery protocols has been analyzed:
Next table briefly compares the protocol features by exploiting the implementation choices reported in the previous figure.| Feature | UPnP | Salutation | SLP | SDP |
| Service and Attribute naming | Template-based and predefined | Template-based and predefined | Template-based | Template-based and predefined |
| Initial communication method | Unicast and multicast | Unicast and multicast | Unicast, multicast and broadcast | Unicast and broadcast |
| Discovery and registration | Query- and announcement-based | Query- and announcement-based | Query- and announcement-based | Query-based |
| Service discovery infrastructure | Nondirectory-based | Directory-based, flat | Nondirectory- or directory-based | Nondirectory-based |
| Service information state | Soft state | Hard state | Soft state | Soft state |
| Discovery scope | Network topology | Network topology | User role and network topology | Network topology |
| Service selection | Manual | Manual | Manual | Manual |
| Service invocation | Service location, communication mechanism, and application operations | Service location, communication mechanism, and application operations | Service location | Service location |
| Service usage | Explicitly released | Explicitly released | Explicitly released | Not available |
| Service status inquiry | Notification and polling | Notification | Not available | Not available |
The middleware architecture implements the D&P by means of specific connectors. The next figure shows a simplified version of the middleware architecture.
Discovery The protocol selected for the discovery of the uSpaces is SLP http://www.ietf.org/rfc/rfc2608.txt. We choose the jSLP-OSGi http://jslp.sourceforge.net/ implementation. jSLP-OSGi is wrapped in the Discovery Connector that control the jSLP-OSGi library in order to:
- announce a new uSpace in the network
- discover all the uSpaces in the network
- discover a specific uSpace in the network
Peering The peering phase is implemented by using one specific communication channel provided by a Communication Connector. The Communication Connector creates a number of communication channels for different purpouses. Among these channels the peering one is reserved for tuning the remote peers:
- Control channel : for control messages
- Bus channel: for bus messages
- Peering channel: for peering message
The role of the discovery is to:
- discover the available uSpaces;
- discover newly registered nodes and nodes that leave the uSpace.
| Artefact: Connector API | |
|---|---|
| Maven artefact | org.universAAL.middleware / mw.connectors.api {.core/.osgi} |
| Pax Composite bundle | scan-composite:mvn:org.universAAL.middleware/mw.connectors.api.osgi/x.y.0/composite |
| Karaf Feature | - |
| Maven Site |
https://universaal.github.io/middleware/middleware.core/mw.connectors.api.core/index.html https://universaal.github.io/middleware/middleware.osgi/mw.connectors.api.osgi/index.html |
| Artefact: SLP Discovery Connector | |
|---|---|
| Maven artefact | org.universAAL.middleware / mw.connectors.discovery.slp {.core/.osgi} |
| Pax Composite bundle | scan-composite:mvn:org.universAAL.middleware/mw.connectors.discovery.slp.osgi/x.y.0/composite |
| Karaf Feature | - |
| Maven Site |
https://universaal.github.io/middleware/middleware.core/mw.connectors.discovery.slp.core/index.html https://universaal.github.io/middleware/middleware.osgi/mw.connectors.discovery.slp.osgi/index.html |
| Artefact: uSpace Module | |
|---|---|
| Maven artefact | org.universAAL.middleware / mw.modules.space {.core/.osgi} |
| Pax Composite bundle | scan-composite:mvn:org.universAAL.middleware/mw.modules.space.osgi/x.y.0/composite |
| Karaf Feature | - |
| Maven Site |
https://universaal.github.io/middleware/middleware.core/mw.modules.space.core/index.html https://universaal.github.io/middleware/middleware.osgi/mw.modules.space.osgi/index.html |
| Artefact: uSpace Manager | |
|---|---|
| Maven artefact | org.universAAL.middleware / mw.managers.space {.core/.osgi} |
| Pax Composite bundle | scan-composite:mvn:org.universAAL.middleware/mw.managers.space.osgi/x.y.0/composite |
| Karaf Feature | - |
| Maven Site |
https://universaal.github.io/middleware/middleware.core/mw.managers.space.core/index.html https://universaal.github.io/middleware/middleware.osgi/mw.managers.space.osgi/index.html |
The SLP protocol will be used in order to discover existing uSpaces, it will be adopted jSLP-OSGi implementation "a pure Java implementation of SLP, the Service Location Protocol, as specified in RFC 2608. The API is derived from RFC 2614 with some modifications. The implementation runs on every Java2 VM, for instance, also on a J2ME CDC Profile. The footprint is less than 80 kBytes for the full version. The SLP Daemon (without stand-alone directory agent) makes jSLP-OSGi very feasible for small and embedded devices." http://jslp.sourceforge.net/.
In order to discover/announce an uSpace, some data structures and operations have been defined. The rest of this section aims at describe how to interact with an uSpace. Every uSpace is described by a data structure named uSpaceDescriptor that wraps the core infos about an uSpace. The fields contained in the descriptor are listed below:
- Space name: name of the uSpace
- SpaceId: unique ID generated internally
- Accessibility: private or public
- Space Description: human readable description
- Space Profile: uSpace profile
- Domain Attributes: profiles or everything
- Channels: information about how to configure the channels for enabling the communication
- Security Card(): keys, certificates and security policies adopted in the uSpace
- SpaceDescriptor CreateSpace (); //to create a new uSpace from scratch
- CreateSpace (SpaceDescriptor); //to create a new uSpace starting from an existing description
- UpdateSpace (SpaceDescriptor); //to update the meta-information about an uSpace
- SpaceDescriptor getManagedSpace() //to fetch the list of uSpace managed by the node
- List getJoinedSpaces() //to fetch the list of uSpace to which the node is bound
- DestroySpace ()
- A node can create just one uSpace. The node role must be COORDINATOR
- Each space will be uniquely identified by the SpaceId automatically generated by the middleware
- Each space will be characterized by the uSpaceDescriptor
- Before creating a space the coordinator looks for equivalent space.
- Equivalent spaces must match the name and ID (that can be found in the uSpaceDescriptor)
- If an equivalent space is found, the node invokes the join operation (if the default behavior of the operation has been configured – different approaches)
- The Space creation implies the propagation of its uSpaceCard, a light representation of the uSpaceDescriptor:
- The coordinator of an uSpace will manage all the join operations invoked by remote peers
- The creation will be notified to the upper layers of the middleware
- Security aspect can be delegated to a trusted service
- Only the node with the COORDINATOR role can destroy its space
- The intent of destroying the space is propagated to all the nodes belonging to the space
- this event gives the possibility to all the peer that join the uSpace to create a persistent state and leave gracefully
- Before finalizing the destroy of an uSpace, the nodes may enter in agreement stats to elect a new coordinator
- Such a behavior can be configured during creation of the space by using specific properties of the SpaceDescriptor
- List lookupSpace(SpaceQuery); //look for a space according to the SpaceQuery
- List getPublicSpaces(); //look for all the public uSpaces
- boolean isEquivalentSpace(SpaceCard, SpaceCard); //check the equivalence between uSpaces
- JoinRequest(SpaceCard, NodeCard); //join to an uSpace
- LeaveRequest (SpaceCard, sessionId) //leave an uSpace
- newPeerAdded(); //to announce to the uSpace a new node
- peerLost(); //to announce a node is going to leave the uSpace
To discover process poses some unique challenges for the discovery of resources in the uSpaces, this section will consider the challenges related to how to set-up the communication between nodes in order to optimize the message exchange. For this purpose it's is important to introduce the peering phase as one of the pillars for the middleware building block. We currently characterize the peering with all the issues concerning the following aspects:
- how to configure or negotiate communication between the discovered middleware instances
- how resources become aware of state changes. E.g. available, unavailable, idle, upgrading, leaving
- renegotiation of the communication. Middleware instances have an intrinsic dynamic life cycle, they can be updated at run-time with new or patched components, in this way new features could be suddenly available during an already started communication session and middleware peers can decide to renegotiate the session in order to improve specific parameters
- security aspects for establishing secure communication between middleware instances, e.g. establish the encryption algorithm or a common seed for key generation.
The Communication Module provides general purpose API in order to send/receive messages to other peers, the Communication Connector wrap the JGroups communication library in order to deliver messages in the uSpace.
| Artefact: Communication Module | |
|---|---|
| Maven artefact | org.universAAL.middleware / mw.modules.communication {.core/.osgi} |
| Pax Composite bundle | scan-composite:mvn:org.universAAL.middleware/mw.modules.communication.osgi/x.y.0/composite |
| Karaf Feature | - |
| Maven Site |
https://universaal.github.io/middleware/middleware.core/mw.modules.communication.core/index.html https://universaal.github.io/middleware/middleware.osgi/mw.modules.communication.osgi/index.html |
| Artefact: jGroups Communication Connector | |
|---|---|
| Maven artefact | org.universAAL.middleware / mw.connectors.communication.jgroups {.core/.osgi} |
| Pax Composite bundle | scan-composite:mvn:org.universAAL.middleware/mw.connectors.communication.jgroups.osgi/x.y.0/composite |
| Karaf Feature | - |
| Maven Site |
https://universaal.github.io/middleware/middleware.core/mw.connectors.communication.jgroups.core/index.html https://universaal.github.io/middleware/middleware.osgi/mw.connectors.communication.jgroups.osgi/index.html |
The peering phase allows resources to share essential configurations useful for establish the communication among two ore more universAAL middleware instances. The peering can be compared to the Session Description Protocol (SDP) session planned during SIP-based communications. SDP is a format for describing streaming media and initialization parameters, it defines multimedia communication sessions for the purposes of session announcement, session invitation, and parameter negotiation. SDP does not deliver media itself but is used for negotiation between end points of media type, format, and all associated properties. More accurately the peering phase is characterized by the implementation choices marked with red circle reported in the figure below.
- Service Discovery: Manual service selection gives to the users the control of which services select after searches have been performed, while with automatic service selection the discovery protocol implements some heuristics to automatically select the best service answering to the client search.
- Service Invocation: The service invocation comprises three different level: service location by specifying the network address, communication mechanisms by specifying the methods used to invoke operations on services, application operation by specifying the available service operations
- Service usage: Clients can explicit release the service resource after the usage or adopt a lease-based mechanism: as soon as the lease expires the client can renew or cancel it
- Service Status Inquiry: Clients can be aware of service events by periodically polling the service, or be asynchronously notified from services as soon as relevant events fire.
- Provide general purpose API in order to send messages.
- unicat channel
- multicast channel
- broadcast channel
- Wrap jGroups library in order to deliver messages in the network
The peering phase uses jGroups Reliable Multicast Communication library http://www.jgroups.org/ in order to create the peering and communication channels. We have defined a data-structure that describes the peering channel (namely the ChannelDescriptor), with the following fields:
- name: a human-readable name for the channel. Examples are unicast-reliable channel, multicast-acked-channel etc.
- channel value: a text-free filed for describing the channel in a free format. Examples can be the a jSON http://www.json.org/ or XML string representing the channel.
- channel URL: the url from which to download a file describing the channel.
- jGroups allows to create a different channels
- Every channel is configured with a protocol stack that defines the protocols to use in order to send/receive messages
- Multiple channels with different protocol stacks can coexist in the same middleware instance
- jGroups implements APIs in order to detect Peers that have configured the same channel
To provide for a higher level of security of the communications between the middleware instances, the middleware can run with encrypted messages. In this way, messages exchanged by the various instances are no longer human readable. For security, Coordinator and Peers must share a unique key. The keyfile must be placed in the /etc folder of the container: The /etc/system.properties file must contain two properties:
universaal.security.enabled=true
bouncycastle.key=${karaf.home}/etc
[1] Zhu, F.; Mutka, M.W.; Ni, L.M.; , "Service discovery in pervasive computing environments," Pervasive Computing, IEEE , vol.4, no.4, pp. 81- 90, Oct.-Dec. 2005 doi: 10.1109/MPRV.2005.87
[2] Edwards, W.K.; , "Discovery systems in ubiquitous computing," Pervasive Computing, IEEE , vol.5, no.2, pp. 70- 77, April-June 2006 doi: 10.1109/MPRV.2006.28