Processing of packets sent and received by Cloudlet Tasks is just performed by a NetworkCloudletSpaceSharedScheduler
manoelcampos opened this issue · 0 comments
FEATURE:
Only the NetworkCloudletSpaceSharedScheduler
class provides the code to send and receive packets. The NetworkCloudletTimeSharedScheduler
didn't have any code to make such a thing it was deleted. By this way, the user is obliged to use the first mentioned scheduler and there is no way to he/she to know that intuitively. Using a different scheduler will just raise class cast runtime exceptions without the user understand why.
Initially it was thought that the network tasks had nothing to do with time or space-shared, just the execution tasks. But it turns out that it has everything to do with it. Even they are network tasks, they depend that their Cloudlets are executing so that packets can be sent or received.
The method updateCloudletProcessing(CloudletExecutionInfo, double)
is dealing with all kinds of tasks according to the scheduler operation, either a time or a space-shared scheduler, but in this way, it should be provided a NetworkCloudletTimeSharedScheduler
that really sends and receives network packets.
CloudletScheduler
interface must be updated to enable any implementing class (such as the CloudletSchedulerTimeShared
or CloudletSchedulerSpaceShared
) to process network packets, whitout requiring to create an specialized NetworkCloudletScheduler
.
Detailed information about how the feature should work
However it will be easier to just include a NetworkCloudletTimeSharedScheduler
that really processes packets, this just causes confusion since the public interface of a Vm and NetworkVm doesn't make clear that it is required a specific NetworkCloudletScheduler
.
Further, providing such NetworkCloudletSchedulers
just causes a proliferation of child classes and doesn't favor composition over inheritance, as it is discussed in #45. Thus, a composition approach should be provided to avoid creating a new child class.
A new independent class must be included and automatically instantiated in the appropriated place and moment to enable the user to use any of the existing regular CloudletScheduler
such as the CloudletSchedulerTimeShared
and CloudletSchedulerSpaceShared
.
An example scenario where this feature should be used
It will start favouring composition over inheritance to pave the way to provide the features in #45.
A brief explanation of why you think this feature is useful
This will make easier and more intuitive to create network simulations. The user will not be surprised by runtime errors due to the use of an unexpected CloudletScheduler.
Final Solution
- Created an independent
TaskScheduler
class and include an attribute of such a class into theCloudletScheduler
. The default value for such an attribute should be aTaskScheduler.NULL
object that implements the Null Object Pattern to avoid NullPointerExceptions when such an attribute is not set (that will be the case were the simulation is not using the network module).
Updates
The TaskScheduler
class was renamed to PacketScheduler
.