Nociones Acerca de las Mariposas

In chapter 3, we have dened assumptions for the design of the Magnetarchitec- ture. Here we summarize them, and discuss the implications for the architecture if these assumptions were not the case. In addition, we propose a solution to possible problems caused by the assumptions being invalid.

1.

Consistency

. All system components are assumed to maintain consistency. That is we assume that: rebinding can be performed only when the system is in a safe state, an unexpected component crash cannot happen, and a com- ponent when nished its operation must leaveMagnet in a consistent state (all tuples from the pool must be withdrawn, and all allocated resources must be released).

Dealing with inconsistency caused by an unsafe rebinding or unexpected com- ponent crash from the component point of view would need a powerful fault tolerant framework (featuring transactions, replications, rollbacks, etc.) This is beyond the scope of this thesis. However, from the Trader point of view, the problem can result in out-of-date tuples being left in the pool. In order to prevent this, the Trader can periodically clean the pool performing garbage collection. However, in order to nd out whether components are still alive, they would be obliged to provide a `still alive' function which would be called by the Trader before removing the tuple. Another solution for clients would be to equip their tuples with timeouts limiting how long their tuples are to wait in the pool, before they can be garbage collected. In addition, in or- der to prevent components from leaving tuples in the pool when they nish the operation, a special subcomponent (present in every component) could automatically withdraw all inserted tuples. However, this solution requires cooperation with the component, in terms of initialization of the operations, so it is not fully automated.

2.

Protection

. By protection we mean that all components, servers and clients, are responsible for ensuring the validity of the tuples.

there is no means to check the validity of the information. Placing a tuple with a non-existent request or oer in the pool can result in an attempt to establish a binding between non-existing components, or incompatible ser- vices. In order to prevent this, the framework can authorize components to call the Trader functions, or introduce capabilities (as tuple elements) to im- prove the component protection. In addition, garbage collection, or the `still alive' function can be used, as discussed in the previous paragraph.

3.

Synchronization

. Components are responsible for synchronization. This includes communication with theMagnet framework as well as component- to-component interaction.

The architecture can provide an additional function for client components (operation BindRet) which would perform the same matching process as operation Bind, and return `no' instead of blocking the component if the requested server has not been found in the pool. There is no need for an equivalent operation to be provided for server components, as they oer ser- vice regardless the interest of clients. As for the component-to-component interaction, there is no reason forMagnet to interfere in synchronization of components themselves.

4.

Security

. The user-dened matching functions are assumed to be secure in terms of returning control back to the Trader, while not altering other system data. The implementation of the matching functions as overloaded C++ functions does not allow the matching function to alter the protected data of other tuple elements, however this does not provide full hardware protection. Furthermore, the architecture cannot check if the function will return the control back to the Trader, as this is the halting problem. This might result in the Trader getting blocked by a `non-secure' function. A solution to this problem, not restricting the extensibility we are aiming for, would be to nish any matching function by force after a timeout period.

5.

Federation Scale

. We assumed the number of components in a federation to be roughly tens, they could generate tens to hundreds tuples placed into the information pool. In addition, more than ten components accessing the Trader at the same time would result in non-acceptable responce time. A high number of components can result in the Trader becoming a bottleneck in the system. The same aect would be observed if more than ten components were accessing the Trader at the same time. We have dealt with this problem in section 6.7.1 discussing possible solutions, for example distributed shared memory. Problems of congestion due to a large number of tuples placed in the pool were discussed in section 6.7.2.

6.

Frequency of Change.

The framework is designed for components that will change their features with a frequency of minutes and hours, rather than seconds and milliseconds. Therefore the proposed support for monitoring and rebinding as a result of a change is adequate.

The support for applications requiring ner grained updates (with frequency of seconds and milliseconds) would not be viable. This can be improved by enabling a direct access to the Tree components for trusted Monitors and Updaters, as suggested in section 5.1.3. However, for environments with very frequent changes, or those which rely on real-time response, our framework is not suitable.

7.

Service Characteristics.

We assumed that tuples have not more than tens of elements, and are equally distributed according to the number of elements (tuple matching size). In addition, we expected the number of types of tuple

elements to be not more than tens.

Exceeding the number of tuple elements, the number of tuple element types, or non-equal distribution of tuples according to the tuple matching size might lead to the problem of congestion of the tuplespace or a particular Tree. We have discussed implications and solutions to this problem in section 6.7.2. 8.

Naming

. Naming of the computing environment used for Trader naming is

assumed to provide unambiguous names in the scale of the environment. In addition, names are constructed in a way that they can form a hierarchical tree structure with a single root, and a unambiguous path in the tree between two Traders can be determined.

If the computing environment does not provide naming which meets these requirements, there must be an additional Trader naming scheme dened. However, it can be derived from common naming schemes, such as ip ad- dresses.

In document El grupo escolar como estrategia para fomentar actitudes de valoración hacia las mariposas en la I E T Valle de Tenza (Guateque, Boyacá) (página 55-64)