New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Processing of packets sent and received by Cloudlet Tasks is just performed by a NetworkCloudletSpaceSharedScheduler #57

Closed
manoelcampos opened this Issue Jan 4, 2017 · 0 comments

Comments

Projects
None yet
1 participant
@manoelcampos
Owner

manoelcampos commented Jan 4, 2017

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 PacketScheduler class and include an attribute of such a class into the CloudletScheduler. The default value for such an attribute should be a PacketScheduler.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).

Examples using this feature

@manoelcampos manoelcampos added this to the CloudSim Plus 1.0 milestone Jan 4, 2017

@manoelcampos manoelcampos self-assigned this Jan 4, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment