EMANE
1.2.1
|
The ConfigurationRegistrar is used by components to register configuration items. Configuration registration provides the emulator with all the knowledge it needs to enforce the correctness of input parameters.
Configuration items can only be registered during Component::initialize. The ConfigurationRegistrar is accessible via the initialize method's Registrar argument.
The ConfigurationRegistrar has two registration template methods which allow components to register numeric and non-numeric configuration items:
Numeric configuration items may have any one of the following types:
Non-Numeric configuration items may have any one of the following types:
Both register calls have parameters to specify a description string, 0 or more default values, min/max occurrence counts (for multiplicity - xml paramlists), item properties such as running-state modifiable and a regex for further validation. Additionally, registerNumeric supports specifying a value range. The emulator will enforce data type, value range, occurrence count, regex match and running-state modification permission without any component interaction.
Configuration Item properties:
An optional validator callable is used by the emulator framework to validate configuration item relationships prior to calling Component::configure or RunningStateMutable::processConfiguration on a component.
A component can register a validator callable using ConfigurationRegistrar::registerValidator.
This callable is passed all known configuration items and returns a std::pair<std::string,bool> where second is either true or false depending on whether the relationship of those configuration items are valid. When an invalid parameter value is detected, first should contain an error description. Configuration updates are transactional, so when a validator returns false the component will not see any of the configuration passed in via configure or processConfiguration.
For example, a model may have a min and max contention window. An invariant would be that min <= max. If a validator testing that invariant was registered, the component would not have configure or processConfiguration called on it if an attempt was made to configure min > max. The validator would detect the error and return false.
The framework keeps a cache of the current running configuration of each component. If an attempt was made to only change a single parameter, in this illustrative case min contention window, the validator would receive all the current cached configuration with the exception of min contention window which would reflect the proposed value (min > max). This provides the validator with all it needs in order to verify all parameter relationships.
The validator callback is executed on an internal framework thread. You should not need to access any shared data in the callable since all known configuration is passed in. However, if for some reason a component needs to access shared data in the callable a synchronization object must be used.
Once processConfiguration is called a component has no ability to reject configuration - that opportunity is provided by the validator callable. The framework will update it's configuration cache and report those values as the new running state.
Both configure and processConfiguration are passed a single ConfigurationUpdate parameter.
For a configuration item with a min/max instance of [0:1], you can safely process the configuration value by accessing element 0. You will only have a configuration item in ConfigurationUpdate if it has 1 or more values.
For a parameter with multiple values, you will have to iterate over them.
When a running-state configuration update is received it is pushed onto the NEM's functor queue as an RunningStateMutable::processConfiguration method. In order for an update to be passed to an NEM it must pass configuration item property checks and any registered validator.