## 4 Proposed Model
### Model Validation  
#### 4.4.1 Load Balancing  
The flowchart presented in Figure 3 describes the load balancing algorithm that manages client requests in an environment that includes cloud servers and fog nodes. When a client makes a request, the system first checks if any cloud server can handle it. If a cloud server is available, the client connects to it. If no suitable cloud server is found, the system searches for the best available fog node to handle the client's request. If a fog node can handle the request, the client connects to it. If all servers and fog nodes are at full capacity, the system prints a message indicating that there is no available capacity and the client cannot connect. Throughout this process, the system assigns the client's request to a specific cluster within the selected server or node, calculates latency, and manages the client's connection. This hierarchical approach ensures a balanced distribution of loads, optimizing both latency and system performance. The use of fog nodes as a backup allows for greater flexibility and handling capacity, which is crucial in high-demand environments such as online gaming. The constant reassessment of system capacity before rejecting a request ensures that the use of available resources is maximized, thus improving the overall efficiency of the system. Under the proposed model, load balancing is dynamic. This means that the decision of which server to send a request to is made in real time, based on the current load of the servers. This task is performed by the get_best_server function in the LoadBalancer class, which selects the nearest server with the least load. This results in lower latency and, consequently, a better quality of experience for the users. Figure 3: Flowchart of the load balancing algorithm. To validate the proposed model, an Events Simulation Software Platform (ESSP) was developed using the Python programming language, which includes the following classes:  
**Server class**: The Server class represents the servers in the proposed model, connected to clusters. It includes several important methods for managing client requests:  
* can_handle_request(): This method checks if the server can handle a new request by comparing the number of connected clients to the server's maximum capacity. This approach ensures that the servers are not overloaded, which is crucial for simulating peak loads. * add_request(client_id, client_location): This method assigns a client request to a server, choosing an available cluster based on the client's location. If the server is available, the client is assigned to a nearby cluster, which optimizes latency. * choose_cluster(client_location): This method selects the cluster closest to the client, using geographic distance as the assignment criterion. This is important for minimizing latency, as clients connect to nearby servers and clusters, improving user experience. * distance(location1, location2): This calculates the distance between two geographical locations. Accurate distance measurement is crucial for calculating latency and correctly assigning requests to nearby servers and clusters. * get_latency(client): This method calculates the latency between the server and the client, considering distance, server load, and network conditions. Latency is a key factor for quality of experience (QoE), and its accurate measurement is critical for validating the model. **Cluster class:** The class cluster, which in the context of an MMO video game, symbolizes the various locations on the map; this class possesses two main attributes: \"id\", which identifies the specific number of the cluster, and \"location\", which indicates the specific position that the cluster occupies within the game. This class also has several attributes:  
* id: Unique identifier for each server. * clusters: List of clusters to which the server can send requests. * capacity: Maximum requests the server can handle simultaneously. * load: Current number of requests the server is handling. * location: Geographical location of the server.