Abstraction Level
This project is a pure simulation and does not represent a real network. We have abstracted the network's structure and protocols to simplify the implementation. The following sections describe the abstraction in detail.
The operating system's structure is abstracted in a general manner.
We have divided our packages into two parts: headers and data sent by clients. Typically, the entire package is transmitted as a byte array. However, in our case, package data is represented as classes and stored in a QVector. Furthermore, each protocol consists of a QVector that stores the header attributes. Each header attribute includes a value, a size in bits, and a name. Lastly, the content data is stored in a separate QVector.
Cables are represented as maps from MAC addresses to pointers to the next network member. As a result, cables do not have any physical limitations (e.g., speed).
Caches are permanent, and the Time-to-Live (TTL) can be set, but is not considered. ARP is not implemented, resulting in ARP caches being initialized at the start. DNS caches are also initialized at the start.
We have only one DNS server that handles all domain resolutions within the network. Authoritative nameservers and additional records cannot be configured. The DNS server is not connected to the Internet and only resolves the domains set at the beginning of the simulation.
Transaction IDs are randomly generated but are not considered in the response. Additionally, the formatting of the answer records is incorrect.
In the request, we only set the method, URI, and version, excluding other details. In the response, we only set the version, code, phrase, and content-type, where the content-type is consistently set to "text/html".
We don't utilize any options within the TCP protocol, resulting in a constant data offset of 0. Only the ACK, PSH, FIN, and SYN flags can be set; all other flags are consistently set to 0. The header length is always set to 5. The urgent pointer is always set to 0. Sequence and acknowledgment numbers are not calculated correctly. The checksum is not calculated correctly. The window size is always set to 65535. The maximum segment size is always set to 1460. The TCP ports are randomly assigned (see Port).
We have not implemented TCP Flow and Congestion Control!
The UDP header length only calculates the length of the UDP header and the content header, which, in our case, refers to the HTML file. It does not take into account the HTTP header length. The checksum is not calculated correctly.
We have exclusively implemented IPv4. The header length is consistently set to 5. The type of service is always set to 0. We do not support IP fragmentation; hence, the fragment offset and fragment flags are consistently set to 0. The protocol is set to 6 (TCP) or 17 (UDP). The checksum is not calculated correctly. The IP addresses are randomly assigned (see IP Address).
The type is set to 0x0800 (IPv4). The checksum is not calculated correctly. The MAC addresses are randomly assigned (see MAC Address).
The abstraction of the packets results in incorrect checksum calculations. Additionally, if the package is modified while traversing the network, the checksum is not recalculated. Moreover, the checksums are not validated.
IP addresses are randomly assigned using the following structure: In a local network, the subnet mask is 255.255.255.0. The router's default IP address always ends with 1, and it increments by one for every host. The router also has a randomly assigned global IP address.
Ports are randomly assigned, while there are no reserved ports. The port range is 0 to 65535. The port 80 is used for HTTP, and the port 53 is used for DNS.
Each device in our network has a randomly assigned MAC address. Organizationally Unique Identifiers (OUI) are not considered. The MAC address range is 00:00:00:00:00:00 to FF:FF:FF:FF:FF:FF.
