Simulator Architecture

This project currently exists as a framework for IoT cluster management, written in Erlang.

The source code consists of several Erlang modules. They are designed to simulate a cluster/server environment that receives incoming clients and attempts to arrange them in an ideal configuration by way of a chosen algorithm. This facilitates comparisons between allocation algorithms to calibrate expedient and efficient cluster-management solutions.

The overseer module presides on the surface level, invoking both simulation operations and the allocation algorithms. It first spawns the specified number of servers, followed by a pseudo-random sequence of connecting clients over an interval of time. It runs the specified algorithm (firstworst or greedy, currently), outputting the resulting allocation to a csv, as was as its initial state.

These outputs are used to compose a visualization a la D3. The current visualization is a before/after snapshot of the clients in the cluster. This snapshot is two bar charts, where each bar represents the number of clients in any number of particular groups on a particular server and each color in the chart represents a particular group number. The before snapshot chart the visualization is of the clients on the cluster before they are load balanced; the after snapshot chart is of the clients on the cluster after they are load balanced.

Currently, the simulator spawns a number of Servers depending on how many the user wishes to spawn.

• They'll be in listen mode as long as the simulator is running, as they are spawned Erlang processes.
• When the server receives a REQUEST message, it responds to the client with how many clients are on that server, if its state is not equal to the maximum server capacity (also selected by the user at the start of the simulation). That is, it tells each client the HIT COUNT. If the server is full, it simply tells the client that it is full.

The simulator also spawns a certain number of clients that the user specifies at the start of the simulation.

• Each client is assigned a group ID (random number between 1 and the number of groups that the user specifies).
• Then, waits for a random period of time before it spawns the next client (to simulate clients actually pinging servers randomly).
• For each client - when spawned, it sends a REQUEST message to any one of the servers (random assignment again). If the server is full, it pings another random server until it has joined a server.

After the clients are spawned, the load-balancing algorithm specified by the user at the start of the simulation is run to move clients in a way such that the amount of inter-server communication between clients of the same group is decreased.

The results are printed to .csv output for the D3 visualization piece of the simulation (as per the discussion above).