Aggie Student Toolkit - Load Balancer Simulation

CSCE 412 Cloud Computing, Project 4 - Arnav Fotedar, Fall 2026

Overview

This program simulates a cloud load balancer that spreads incoming web requests across a pool of web servers and grows or shrinks that pool as demand changes. Time advances in discrete clock cycles. Each request needs a random number of cycles of processing, and each server works on one request at a time.

Core classes

• Request (struct) - one web request: source IP, destination IP, processing time in clock cycles, arrival cycle and job type (P = processing, S = streaming).
• WebServer - processes one Request at a time, counting down its remaining cycles; it can be marked as retiring so it finishes its current request before it is removed.
• LoadBalancer - owns the FIFO request queue and the server pool. Every cycle it completes work, admits arrivals through the Firewall, adjusts capacity and dispatches queued requests to idle servers.

Supporting classes: RequestGenerator (seeded randomness), Firewall (IP range blocker), Logger (colored verbose/quiet output), Simulation (clock and log summary), Config (user input), and Switch (bonus: routes P and S jobs to two separate load balancers).

Clock cycle workflow

1. Initialization: create the servers, generate servers x 100 requests as the starting queue, and dispatch at time 0.
2. Complete work: every busy server advances one cycle.
3. Admit arrivals: a Poisson-distributed number of new requests is generated (average 0.45 per cycle, rising and falling in a slow traffic wave between 0.18 and 0.72); blocked source IPs are rejected before queueing.
4. Adjust capacity: every 10 cycles, add a server if queue > 80 x servers, or remove one if queue < 50 x servers.
5. Dispatch: assign the oldest queued requests to idle servers.

Design choices

• FIFO scheduling with std::queue so older requests are served first; servers are scanned in id order, making runs repeatable with a seed.
• Elastic capacity: proportional thresholds with a cooldown prevent the pool from oscillating every cycle. Scale-down prefers idle servers and otherwise retires a busy one after its request, so no work is lost.
• Firewall before the queue: blocked requests never consume queue space or server time, modeling protection against a denial-of-service source.
• Traffic wave: arrivals follow busy and quiet periods (like day and night traffic), so the 100,000-cycle run shows the pool growing and shrinking repeatedly instead of settling at one size.
• Reproducible randomness: a single seeded std::mt19937 generates every IP address, task time, job type and arrival count.
• Accountability: the summary checks that every request is either rejected, discarded, completed, still queued or in service.

Building and running

make                  # build ./loadbalancer
./loadbalancer        # asks for servers, cycles, task range, seed, mode
make run              # required run: 20 servers, 100000 cycles, quiet, writes logs/
make demo             # short verbose run in color
make switch           # bonus switch run
make docs             # generate this Doxygen site in docs/html

Status lines show the queue size, live servers (busy, idle, retiring), completed, rejected and discarded requests, and scaling counts.

Related pages: design document at https://people.tamu.edu/~afotedar05/project4/