RAKUB Engineer Exam 5 June 2026 — Question Solution | রাকাব প্রকৌশলী নিয়োগ পরীক্ষা ২০২৬ — প্রশ্ন সমাধান

Answer: Utilisation with stop-and-wait = 1/63.5 ≈ 1.57 %; the minimum window for 100 % utilisation = 64 frames.

Given: propagation delay Tp = 250 ms, rate R = 1 Mbps = 10⁶ bps, frame size L = 1000 bytes = 8000 bits. ACK transmission and processing times are taken as negligible, as is usual.

Step 1: transmission time of one frame
Tt = L ÷ R = 8000 ÷ 10⁶ = 0.008 s = 8 ms

Step 2: the ratio a
a = Tp ÷ Tt = 250 ÷ 8 = 31.25

Step 3: stop-and-wait utilisation
In stop-and-wait the sender sends one frame, then waits for its ACK. One cycle = Tt + 2Tp (frame goes up to the satellite link end, ACK comes back).

• Cycle = 8 + 2 × 250 = 508 ms
• U = Tt ÷ (Tt + 2Tp) = 8 ÷ 508 = 1 ÷ (1 + 2a) = 1 ÷ 63.5 = 0.015748 ≈ 1.57 %
• Effective throughput = U × R = 0.015748 × 1 Mbps ≈ 15.75 kbps

So the 1 Mbps link is busy only 8 ms out of every 508 ms; for 98.4 % of the time it is idle.

sequenceDiagram
    participant S as "Sender (ground)"
    participant R as "Receiver"
    S->>R: "Frame 1 (Tt = 8 ms, arrives after Tp = 250 ms)"
    R-->>S: "ACK 1 (another 250 ms)"
    Note over S: "Link idle 500 ms per frame"
    S->>R: "Frame 2 only after ACK 1, 508 ms cycle"

Step 4: minimum window for 100 % utilisation (sliding window)
With a window of W frames, the sender can push W frames per cycle:
U = W × Tt ÷ (Tt + 2Tp), valid while W < 1 + 2a.
Set U = 1:
W = (Tt + 2Tp) ÷ Tt = 1 + 2a = 1 + 2 × 31.25 = 63.5
A window must be a whole number of frames, so W = 64 frames (the sender is never idle because the first ACK returns before the 64th frame finishes).

Window W	U = W × 8 ÷ 508
1 (stop-and-wait)	1.57 %
7	11.0 %
32	50.4 %
64	100 % (≥ 63.5)

Sequence-number bits needed for W = 64

• Go-Back-N: W ≤ 2ᵏ − 1 → 64 ≤ 127 → k = 7 bits
• Selective Repeat: W ≤ 2ᵏ⁻¹ → 64 ≤ 64 → k = 7 bits

Check: 64 frames × 8 ms = 512 ms ≥ 508 ms cycle, so the pipe stays full; 63 frames × 8 = 504 ms < 508 ms would leave a 4 ms gap.

Exam tip: remember U = 1 ÷ (1 + 2a) for stop-and-wait and W = 1 + 2a (rounded up) for full utilisation; long-delay satellite links are exactly why sliding windows are used.

Answer (root cause): the database host has run out of file descriptors and socket resources in the kernel. In Linux every TCP connection is a socket, and every socket is a file descriptor (FD). Under peak load the database process (and the app) opens connections faster than they are released. The process hits its per-process open-file limit (RLIMIT_NOFILE) or the system-wide limit (fs.file-max), so the kernel refuses new sockets with EMFILE/ENFILE "Too many open files". New connections cannot be accepted, they pile up in the listen backlog until it overflows, and clients see connection timeouts.

How the kernel resources run out

Kernel resource	Limit	What happens when exhausted
Per-process FD table	ulimit -n / RLIMIT_NOFILE (soft limit commonly 1024)	accept(), socket(), open() fail with EMFILE: Too many open files
System-wide file table	/proc/sys/fs/file-max	ENFILE: Too many open files in system
Listen (accept) queue	listen() backlog, capped by net.core.somaxconn (4096 by default since kernel 5.4)	Queue full → SYNs/ACKs dropped → client connect timeout
Ephemeral ports	net.ipv4.ip_local_port_range = 32768–60999 → 28,232 ports	connect() fails with EADDRNOTAVAIL
TIME_WAIT sockets	Each actively closed socket waits 60 s (2 × MSL)	Ports stay occupied after close

The failure chain at peak load

flowchart TD
    A["Peak traffic: many web requests"] --> B["App opens a new DB connection per request, or leaks them (no pooling)"]
    B --> C["Each connection = socket = 1 FD in the DB process"]
    C --> D{"FDs in use reach RLIMIT_NOFILE?"}
    D -->|"Yes"| E["accept() fails: EMFILE Too many open files"]
    E --> F["Listen backlog fills (somaxconn)"]
    F --> G["Kernel drops new SYNs"]
    G --> H["Clients: database connection timeout"]
    B --> I["Short-lived connections closed → TIME_WAIT 60 s"]
    I --> J["Ephemeral ports exhausted: socket exhaustion"]
    J --> H

Worked numbers

• If the DB process has a soft limit of 1024 FDs and already uses about 100 for data files, logs and libraries, it can hold only about 924 client sockets. A burst of 1500 concurrent connections fails.
• Port exhaustion: 28,232 ephemeral ports ÷ 60 s TIME_WAIT ≈ 470 new connections per second sustained between the same app IP and the same DB IP:port. Opening and closing a connection per request above that rate exhausts the ports.

Why it appears "suddenly"
These limits are hard thresholds. Below them everything is normal; one step above, every new connection fails. A connection leak or missing pool raises FD usage steadily until the peak pushes it over.

Diagnosis (on the DB host)

cat /proc/<pid>/limits | grep "open files"   # the process's FD limit
ls /proc/<pid>/fd | wc -l                    # FDs in use now
cat /proc/sys/fs/file-nr                     # system-wide allocated / max
ss -s                                        # socket summary, TIME_WAIT count
ss -ltn                                      # Recv-Q on the listen socket = backlog filling

Fix

1. Connection pooling in the app (e.g. HikariCP) or a pooler (PgBouncer, ProxySQL); fix leaked connections (always close them).
2. Raise limits: LimitNOFILE=65535 in the database's systemd unit (/etc/security/limits.conf applies only to login sessions, not to systemd services); raise fs.file-max if the system limit is hit.
3. Tune the network stack: larger net.core.somaxconn and listen backlog, net.ipv4.tcp_tw_reuse = 1 on the client side, a wider ip_local_port_range, persistent (keep-alive) connections.
4. Align the database's own max_connections with the pool size and monitor FD usage.

Exam tip: "too many open files" = file-descriptor limit; sockets are FDs. The cure is pooling plus higher limits, not just restarting the server.