On the agent side, the parameter schedulerModule has to be
set to the path of the module scheduler (in the agent configuration
file). This option uses the same syntax than the other agents and ORB
options:
schedulerModule = path to module
On the SeD side, the developer has to choose DIET_AGG_USER as
aggregator:
diet_aggregator_desc_t *agg;
diet_service_table_init(1);
profile = diet_profile_desc_alloc("serviceName", ...);
diet_generic_desc_set(diet_param_desc(profile, 0), ...);
...
agg = diet_profile_desc_aggregator(profile);
diet_aggregator_set_type(agg, DIET_AGG_USER);
diet_service_table_add(profile, ...);
...
Usually, the developer should define a performance metric function to
communicate with the agent scheduler. For example, if the scheduler uses
the number of waiting jobs in the FIFO queue, the performance metric
could be:
void metric(diet_profile_t * profile, estVector_t values) {
diet_estimate_waiting_jobs(values);
}
This metric just fixes the number of waiting jobs in the FIFO queue of the
SeD . Now, at the agent side, the scheduler can use this value to aggregate,
sort and filter the SeD s responses. More details are given in the following
section about how to use the SeD s plugin schedulers to communicate with the
agent scheduler module.