In conventional component-based adaptation middleware, there is only one component chain or actuator per application at each host. However, due to the operation suspension and buffer clearance during the component-chain reconfiguration process, both the overhead and delay are intolerably large for some real-time distributed applications.

By contrast, MassWare uses multi-actuator architecture with shared components Proactive actuators are constructed when the adaptation rules are parsed by connecting the references of the marchlets, which are instantiated when the masslets segment is parsed. To reduce the resource consumption by the multiple actuators, each actuator only consists of a list of references that point to the masslet instances and maintains a customized parameter list for each masslet reference. Thus all actuators share the masslets and only one of the actuators is active at any time. The actuator modification process in the conventional single-actuator architecture is replaced by the switching process of the active and inactive actuators in the MassWare architecture. When the context changes and a new event condition is met, the current active actuator is either stopped after storing the component states to its parameter list or deactivated after completing its currently task. And the new actuator subscribed to the new sensor will be reinitialized with its parameter list and activated to process the application data.

Since each distributed application at a host has its own actuator, architecture synchronization is a crucial service of the middleware for dynamic reconfiguration to achieve behavior consistency among the distributed actuators. We have designed an efficient synchronization protocol in MassWare based on active messages, which has the following initialization steps as depicted in figure.

1. In the initialization phase of a middleware agent, proactive actuators are constructed based on the script file. Each proactive actuator is associated with a middleware-assigned unique index and some architecture information of an optional reactive actuator.

2. The middleware agent of the proactive actuators sends a synchronization request packet to each distributed peer agent. The packet contains the indices of the proactive actuators and the architecture information of the reactive actuators.

3. After receiving the synchronization request packet, the peer agent constructs the reactive actuators, each of which is associated with the IP address of the packet sender and a middleware-assigned unique index, according to the packet information.

4. The receiver or the peer agent returns the sender a synchronization response packet that includes related index pairs, each of which contains the indices of the proactive and reactive actuators.

5. The sender agent then replaces the architecture information of each reactive actuator with the corresponding index received from the synchronization response packet. 

The above-mentioned initialization is a one-time process for each peer agent. Then the middleware agent of the proactive actuators appends the index of the corresponding reactive actuator to the data payload. The peer agent receiving the data packet activates the reactive actuator indexed by the received index to process the data. If the peer agent does not recognize the received index, it sends a synchronization query packet to the sender agent to ask for the synchronization request packet. When the agent of the proactive actuators terminates, it sends a synchronization termination message to all its distributed peers so that they can release the related reactive actuators.

The active message based synchronization protocol has four advantages: low overhead, short delay, high efficiency, and better robustness. In general, one byte is sufficient for the size of the active message header in the data packets, which is used to store the index of the reactive actuator. By using the actuator switching method, the system does not need to be paused in the reconfiguration process, which dramatically reduces the reconfiguration time. Based on the information in the active message header, a peer agent can process the received packets by choosing the correct reactive actuator. Therefore no buffered clearance is needed, which makes the component reconfiguration by our middleware efficient. Moreover, once the initialization phase is done, the receiver agent does not need to be re-synchronized with the sender agent in the reconfiguration process. Thus, the robustness of the distributed application is improved and communication overhead is reduced.

Active Message: Design challenges of virtual networks: Fast, general-purpose communication

Active Message Communication for Tiny Networked Sensors