The new PIM model will have to be:
- easier to configure, program and maintain
- more reactive to environmental changes
- able to support flexible CP migrations
- capable of dealing with several sets of nodes
- resilient to node failures
- economic in terms of resource consumption (e.g. bandwidth, power)
The new proposed architecture at a glance
To satisfy the requirements of configurability and ease of programming, we want the new PIM model to be very modular.
This way we will be able to develop different versions of each module, leaving at the CP programmer the freedom to choose which one to use. Furthermore, the CP programmer will have the freedom to replace each module with others of his own. The idea is to maintain code complexity at a very low level when no particular customization is needed, while leaving the architecture as configurable as possible. In the following picture it is represented the current prototype of the new PIM model.
The PIM architecture is divided in two parts:
- the movable part: this part is unique in the system and it is constantly migrated between each member of the team. It contains the CP and all the modules necessary for the interaction with the resident part. In particular, it contains the following modules:
- NodeLifeCycleListener: this module will be notified of any topology changes. On top of these events, it will decide whether to include or remove nodes from the team.
- MigrationScheduler: here, a list of nodes is computed, and sorted (e.g. from the one the CP would like to visit sooner to the one in would like to visit later).
- NodeManager: this component will keep trace of all the nodes present in the nearby, along with their type and status. As for now, we think that this component will host the caching mechanism
- the resident part: this part is resident on each member of the team. It contains the modules needed to interact with the local robot, to migrate the CP and to maintain an updated view of the topology. In particular, the LocalRobot class will be the container for all this modules and, depending on the robot type, it will provide different methods to interact with the underlying hardware. The included modules are the following:
- NodeMonitor: this component will have to detect topology changes, advertising the NodeLifeCycleListener. Moreover, it will have to implement part of the fault-tolerance mechanism. As for now, we are thinking to avoid the use of the GroupManager because of its high bandwidth consumption.
- MigrationManager: this module will manage the migration of the CP, triggering the fault-tolerance mechanism if the CP is considered dead.
Note: Probably we will need to rename the LocalRobot class, because sometimes we won't deal with robots at all.
As for now, we are focusing on:
- reducing the network traffic required to:
- keep an updated representation of the network topology
- migrate the CP
- improve the overall reactivity regarding environmental changes, migrating the CP where its presence is most needed
- evaluate the communication overhead for detecting network topology changes
To see how we think to implement this new model, take a look at the following pages: