Network Structure

[alyhasansakr]

We wish to have our own independent network structure.

Basic elements that need to be implemented are:

• Location: A physical location that may contain devices, physical locations are connected together using network connections.
• Device: A piece of hardware that can run applications, it may have compute limits (CPU, memory, ..).
• Application: A piece of software that runs on a device.
• Connection: A network connection between two locations, it may have network limits (bandwidth, delay, ..).

As a start, you should define each of these elements as a separate class. Then make an output that can be used to build (piece by piece), load, and save networks as follows:

• Building a network should be more or less the constructors of each element.
• Loading a network should receive the full network as a JSON string.
• Saving the network should trigger an input that sends the network as a JSON string.

The implementation should be based on the new module definition in #69 (you may have to wait until it is finished). You may need to implement other classes than mentioned here.

Before you start implementation, write down your exact solution specifying the attributes and methods of each element (text or diagrams).

And don't forget the tests, both for the module as well as for each class.

[lkh5kor]

Hi @alyhasansakr ,

To start with the tasks, can you please clarify the below queries.

1. The Location class should contain the latitude, longitude , requester device information(taken from device class), type of request (should all "sip", "acr", "tel" be supported?) Any more data is missed?
2. The device class should have device id, device name, device address, device type (UE,POA,FOG,EDGE,CLOUD), CPU limit(min and max), Memory limit (min and max). Have I missed anything here?
3. The connection class should contain source location, destination location, time, Round-trip latency, Uplink throughput, Downlink throughput, Uplink packet loss. Is any status regarding connection between source and destination required?
4. With respect to application class, can you kindly provide more details.

Regards, Shankar

[alyhasansakr]

@lkh5kor Our implementation here is a general implementation, it is not specific to any platform or framework. In the current step, we wish to define the existence of these elements as well as their attributes. No functionality is required here (for now).

To answer your questions:

1. A location should have id, latitude and longitude. Don't add anything else unless you have a good reason for it.
2. A device should have id, address, type and compute limits. Compute limits should be a separate class with its own definitions.
3. A connection could either be defined as one-way or two-way, I prefer one-way. So a one-way connection should have id, source location, destination location and Network limits. Just as compute limits, network limits is a separate class with its own definition.
4. For the application we don't need any functionality to be implemented. But we still need to define two different classes: application type (images in Docker) and application instance (containers in Docker). An application type has id, compute requirements and network requirements (own classes as well). An application instance has only an application type.

Keep in mind that I didn't mention how they should be connected together, for example, how to specify which two locations are connected by a connection. I would be happy to see what do you have in mind here, but first do the class diagram for all of the elements.

[lkh5kor]

@alyhasansakr,

Based on my understanding, I have done the initial class diagram with only members and member functions. Kindly review the same. I would proceed to the detailed class diagram(with all the connections) after the review

[alyhasansakr]

@lkh5kor Looks good overall, here are my comments:

1. I still prefer one-way connections, that is only from source to destination and not the other way. Which means there should be only one throughput value, one packet loss value, and delay is not roundtrip.
2. What is time in network limits?
3. You don't need to mention that a connection has a source and destination locations, this should be indicated in the relationship between them (just the same as you didn't mention that a device exists in a location).
4. I don't understand why do we have a min and max values for requirements and limits?
5. Why did you merge the memory requirements with compute requirements but not the limits?
6. You don't need to mention typical setters and getters in this diagram.
7. Don't use any short names like D2S or comSpec.
8. Device type should also be a class with attributes because we may have movable devices (phones, cars) and non-movable devices (servers).

[lkh5kor]

@alyhasansakr please find my answers below

1. I still prefer one-way connections, that is only from source to destination and not the other way. Which means there should be only one throughput value, one packet value, and delay is not roundtrip. I will remove the other parameters

2. What is time in network limits? Time in network limits is the timestamp data. If not required, I can remove it

3. You don't need to mention that a connection has a source and destination locations, this should be indicated in the relationship between them (just the same as you didn't mention that a device exists in a location). Will make the changes in the detailed class diagram.

4. I don't understand why do we have a min and max values for requirements and limits? My idea of min value was to check that the provided value should always be greater than the min value(required value from requirement) and lesser than or equal to the max available resources. I will add additional parameter "availablecpu" and "availableMemory" to the requirements to serve the same purpose if needed.

5. Why did you merge the memory requirements with compute requirements but not the limits? Idea was to have a single class for requirements, I will split it into multiple classes

6. You don't need to mention typical setters and getters in this diagram. I will remove the setters and getters in the detailed diagram

7. Don't use any short names like D2S or comSpec. Change would be made in the detailed diagram. since it is one way communication that we are interested in, I don't think D2S and S2D is even required.

8. Device type should also be a class with attributes because we may have movable devices (phones, cars) and non-movable devices (servers). Change would be made in the detailed diagram.

[lkh5kor]

@alyhasansakr ,

Please find the updated class diagram as per my understanding. Kindly review and provide feedback.

[alyhasansakr]

@lkh5kor Fantastic, that is a very good one. Now we should start with implementation. Branch the master, make a new folder here called Network Structure and start creating these classes. After that make a pull-request so we can discuss the code there.

[alyhasansakr]

Just for documentation: A relationship class should be created (only in implementation) for relationships between: location-connection, location-device, application_instance-device. A network class that contains lists of all structural elements should be created. Structural elements are: connection, location, device, application instance, and the relationships between them. The network class should implement write to and read from JSON string.