Given:

• One-way propagation delay (Tp) = 250 ms = 0.25 s
• Transmission rate (Bandwidth) = 1 Mbps = 10⁶ bits/s
• Frame size = 1000 bytes = 1000 × 8 = 8000 bits
• Protocol: Stop-and-Wait

Step 1: Calculate Transmission Time (Tt)
Tt = Frame size ÷ Bandwidth
Tt = 8000 bits ÷ 10⁶ bits/s = 0.008 s = 8 ms

Step 2: Calculate Round Trip Time (RTT)
RTT = 2 × Tp = 2 × 250 ms = 500 ms

Step 3: Calculate Efficiency (Utilization) for Stop-and-Wait
Efficiency = Tt ÷ (Tt + RTT)
Efficiency = 8 ÷ (8 + 500) = 8 ÷ 508 = 0.0157
Efficiency = 1.57%

Step 4: Calculate Minimum Window Size for 100% Efficiency
For 100% efficiency, the sender must keep the channel fully utilized. This means the window size must be large enough so that the total transmission time of all frames in the window equals or exceeds the RTT.

Window size (N) = RTT ÷ Tt
N = 500 ÷ 8 = 62.5
N = 63 frames (rounded up to the nearest whole number)

Alternatively, using the formula:
Efficiency = (N × Tt) ÷ (Tt + RTT)
For 100% efficiency: N × Tt ≥ Tt + RTT
N ≥ (Tt + RTT) ÷ Tt = (8 + 500) ÷ 8 = 63.5
N = 63 or 64 frames

Given:
Destination IP: 192.168.20.45
Routing table entries:

• 192.168.0.0/16
• 192.168.16.0/20
• 192.168.20.0/22
• 192.168.20.32/25

Step 1: Check Each Route for Match

A packet matches a route when the destination IP ANDed with the subnet mask equals the network address.

Step 2: Apply Longest Prefix Match Rule
When multiple routes match, the router selects the one with the longest subnet prefix (most specific network).

Final Answer:
The router will forward the packet to the interface associated with 192.168.20.32/25 because it has the longest prefix match (25 bits), making it the most specific route.

Why This Rule Exists:
Longest prefix match ensures traffic is sent through the most precise path. A /25 network is a smaller, more targeted subnet than a /16 network. If a company has a general route for all 192.168.x.x traffic but also a specific route for a small department subnet, the specific route should win for packets going to that department.

IPv6 header architecture enables faster processing than IPv4 due to several design simplifications that reduce router workload at each hop.

• Fixed header size: IPv6 uses a fixed 40-byte header. IPv4 has a variable header length (20 to 60 bytes) because of optional fields, forcing routers to parse and calculate the actual header size every time.
• No header checksum: IPv6 removes the header checksum entirely. IPv4 routers must recalculate and verify the checksum at every hop, adding CPU overhead. IPv6 delegates error detection to upper-layer protocols like TCP and UDP.
• No router fragmentation: IPv4 allows routers to fragment packets when they are too large, which requires complex reassembly logic. IPv6 only permits fragmentation by the source host, so routers never perform this task.
• Simplified header fields: IPv6 has fewer header fields (8 vs 14 in IPv4), making parsing faster. Fields like Header Length, Identification, Flags, Fragment Offset, and Options are removed or relocated to extension headers.
• Extension headers: Optional features in IPv6 are placed in separate extension headers that routers can skip unless specifically needed, unlike IPv4 where options are embedded in the main header.

Comparison Table:

Understanding Precision and Recall

• Precision: Out of all cases the model predicted as failure, how many were actually failures. High precision means few false alarms.
• Recall: Out of all actual failures that exist, how many did the model correctly catch. High recall means few missed failures.

Why Recall Matters More Here

When the business penalty for a missed failure is catastrophic — such as complete network downtime, data center collapse, financial loss, or safety hazards — the administrator must prioritize catching every possible failure even if it means raising more false alarms.

• False Positive (Low Precision): The model predicts a failure that does not exist. Cost = technician time for inspection, minor inconvenience.
• False Negative (Low Recall): The model misses a real failure. Cost = catastrophic outage, millions in losses, damaged reputation, potential harm to users.

The recall-focused model wastes technician hours but prevents the one missed failure that would destroy the business. In critical infrastructure, survival beats efficiency.

Practical Steps to Optimize Recall

• Lower classification threshold: Accept more predictions as positive to catch edge cases.
• Class weights: Penalize the model heavily during training for missing real failures.
• Ensemble methods: Combine multiple models so if one misses, another catches it.
• Anomaly detection: Flag anything unusual for human review rather than automatic dismissal.

Amdahl’s Law

Amdahl’s Law is a formula that calculates the theoretical maximum speedup of a system when only a portion of it is improved. It shows that the overall speedup is limited by the fraction of the program that cannot be parallelized, no matter how many CPU cores are added.

Mathematical Formula

Speedup = 1 / [(1 − P) + (P / N)]

Where:

• P = Fraction of the program that can be parallelized (0 to 1)
• (1 − P) = Fraction that must run sequentially and cannot be sped up
• N = Number of CPU cores (processors)

How It Dictates Maximum Speedup

The law reveals a harsh truth: even with infinite cores, the speedup can never exceed 1 / (1 − P). The sequential portion becomes a hard ceiling.

• If P = 0.9 (90% parallelizable): Maximum speedup with infinite cores = 1 / 0.1 = 10×, no matter how many cores are added.
• If P = 0.5 (50% parallelizable): Maximum speedup = 1 / 0.5 = 2×, even with thousands of cores.
• If P = 0.99 (99% parallelizable): Maximum speedup = 1 / 0.01 = 100×.

Example Calculation
A program spends 70% of its time on parallel tasks and 30% on sequential tasks. With 8 cores:
P = 0.7, N = 8
Speedup = 1 / [(1 − 0.7) + (0.7 / 8)]
Speedup = 1 / [0.3 + 0.0875]
Speedup = 1 / 0.3875 = 2.58×

Even with 8 cores, the speedup is only 2.58× because the 30% sequential part drags everything down.

Key Insight: Adding more cores gives diminishing returns. The bottleneck is always the sequential portion. To achieve massive speedups, programmers must minimize the fraction of code that cannot run in parallel.

The failure is caused by resource exhaustion at the Linux kernel level, specifically involving file descriptors and network sockets under high load.

Key Root Causes:

File Descriptor Exhaustion:
Linux treats files, sockets, and network connections as file descriptors.
The error “too many open files” indicates that the process or system has exceeded the ulimit (open file descriptor limit) configured in the kernel.

Socket Exhaustion:
Each database connection uses a TCP socket, which also consumes file descriptors.
Under peak load, too many simultaneous connections exhaust available kernel socket resources.

Kernel Resource Limits (ulimit / sysctl constraints):
The Linux kernel enforces limits such as:

• Maximum open files per process (ulimit -n)
• System-wide file descriptor limit
• TCP socket backlog limits

When these limits are reached, new connections are refused or time out.

Connection Leak / Poor Connection Pooling:
Application may not be closing database connections properly or lacks connection pooling, causing accumulation of open sockets.

Why Timeouts Occur:
When kernel resources are exhausted:

• New TCP connections cannot be created
• Existing connection requests remain in SYN queue or wait state
• Database connection attempts fail → timeout errors

The root cause is Linux kernel-level resource exhaustion, mainly due to hitting file descriptor limits and socket limits under peak load, often worsened by insufficient connection management in the application layer.

WHERE vs HAVING Clause in SQL

In SQL, both WHERE and HAVING are used to filter data, but they operate at different stages of query execution and serve different purposes. Understanding their distinct behaviors is essential when working with aggregate functions like SUM, COUNT, AVG, MIN, and MAX.

1. WHERE Clause

The WHERE clause filters individual rows before any grouping or aggregation takes place. It operates on raw data from the table.

• Stage: Executes before GROUP BY and aggregate functions.
• Scope: Filters individual rows based on column values.
• Aggregate functions: Cannot use aggregate functions like COUNT(), SUM(), or AVG().
• Performance: Reduces the number of rows early, making aggregation faster.

Example:
Select only employees from the Sales department before calculating average salary.

SELECT dept, AVG(salary) FROM employees WHERE dept = 'Sales' GROUP BY dept;

Here, WHERE filters rows where dept is ‘Sales’ first, then AVG is calculated only on those rows.

2. HAVING Clause

The HAVING clause filters groups of rows after grouping and aggregation have been completed. It operates on the result of aggregate functions.

• Stage: Executes after GROUP BY and aggregate functions.
• Scope: Filters groups based on aggregate results.
• Aggregate functions: Can and typically does use aggregate functions.
• Performance: Works on already aggregated data, so it cannot reduce early row processing.

Example:
Show only departments where the average salary is greater than 50,000.

SELECT dept, AVG(salary) FROM employees GROUP BY dept HAVING AVG(salary) > 50000;

Here, GROUP BY creates department groups, AVG calculates the average, and HAVING filters out groups where the average is too low.

3. Execution Order in SQL

SQL processes clauses in this order, not in the order they appear in the query:

4. Combined Example

Find departments in the Sales region where total sales exceed 100,000.

SELECT region, SUM(sales) AS total FROM orders WHERE region = 'Sales' GROUP BY region HAVING SUM(sales) > 100000;

• WHERE region = ‘Sales’: Filters individual rows to only Sales region orders.
• GROUP BY region: Groups the remaining rows by region.
• SUM(sales): Calculates total sales per region.
• HAVING SUM(sales) > 100000: Keeps only regions where the total exceeds 100,000.

Cross-Site Scripting (XSS) is an attack where malicious scripts are injected into trusted websites. The key difference between Reflected and Stored XSS lies in how the payload reaches the victim.

1. Reflected XSS

In Reflected XSS, the malicious payload is embedded in a URL or request and delivered to the victim through social engineering. The server reflects the payload back in the response without storing it.

• Delivery method: The attacker crafts a malicious link containing the script and tricks the victim into clicking it — via email, chat messages, or fake websites.
• Server role: The server receives the payload in the request (like a search query or form input) and immediately includes it in the response page.
• Storage: The payload is never stored on the server. It exists only in the single request-response cycle.
• Victim trigger: The victim must actively click the malicious link or submit a crafted form.

Example: An attacker sends an email with a link like:
https://bank.com/search?q=<script>stealCookie()</script>
When the victim clicks, the bank site reflects the script in the search results page and it executes.

2. Stored XSS

In Stored XSS, the malicious payload is permanently saved on the server (in a database, comment field, or user profile) and delivered to every victim who views the infected content.

• Delivery method: The attacker submits the payload through a form, comment box, or any input that the application saves. Later, when other users load that page, the server serves the stored script.
• Server role: The server stores the payload and includes it in responses to multiple users over time.
• Storage: The payload is persistently stored on the server in a database or file.
• Victim trigger: The victim only needs to visit the infected page. No click on a special link is required.

Example: An attacker posts a comment on a blog containing:
<script>stealCookie()</script>
Every visitor who loads that blog post automatically executes the script.

Comparison Table:

Problem:
A corporate network pool experiences IP exhaustion due to a high volume of transient guest devices.
Root Cause:
Guest devices connect briefly (for minutes or hours) but the DHCP server assigns them IP addresses with long lease durations (days or weeks). These addresses remain reserved even after guests leave, preventing reuse and quickly depleting the pool.
Solution:
Reduce the DHCP lease duration to a much shorter time period — typically 2 to 4 hours for guest networks .
How It Works:

• Shorter lease: When a guest disconnects, the IP address returns to the available pool within hours instead of days.
• Faster recycling: The DHCP server can reassign freed IPs to new guest devices almost immediately.
• Balanced timing: Too short (under 30 minutes) causes excessive DHCP traffic (renewal requests). Too long fails to solve exhaustion.

Additional Measures:

• Separate VLANs: Isolate guest traffic on a dedicated subnet to protect corporate resources.
• Smaller subnets for guests: Use /23 or /22 subnets to expand available IPs without affecting main corporate pool.
• MAC address filtering: Limit how many IPs one device can claim.

When a network admin notices excessive broadcast traffic, it means too many broadcast packets are being sent in the LAN, reducing network performance and bandwidth efficiency.

Possible Causes:

• Broadcast storms: Caused by network loops in switching topology (often due to lack of STP).
• Faulty network devices: A misconfigured switch or NIC may generate continuous broadcasts.
• ARP traffic overload: Large number of devices frequently sending ARP requests.
• Flat network design: Too many devices in a single broadcast domain.
• Malware or misbehaving applications: Generating unnecessary broadcast packets.

Solutions:

• Enable Spanning Tree Protocol (STP): Prevents switching loops and broadcast storms.
• Segment the network using VLANs: Reduces broadcast domain size.
• Use routers to control broadcast domains: Routers do not forward broadcasts.
• Fix faulty devices: Identify and replace misconfigured or malfunctioning hardware.
• Monitor traffic: Use network monitoring tools to detect abnormal broadcast activity.

Excessive broadcast traffic is mainly caused by loops, poor segmentation, or faulty devices. It can be controlled by using STP, VLAN segmentation, and proper network design.

Errors in programming can occur at two main stages: when the code is being translated into machine language (compile-time) and when the program is actually running (runtime). Understanding the difference helps in faster debugging and writing more reliable code.

1. Compile-Time Error

A compile-time error is detected by the compiler before the program is executed. It means the code violates the rules of the programming language and cannot be translated into an executable program.

• When detected: During compilation, before the program runs.
• Cause: Syntax mistakes, type mismatches, missing declarations, or incorrect language structure.
• Fix: The programmer must correct the code and recompile.
• Program state: The program does not generate an executable file.

Examples:

• Missing semicolon at the end of a statement.
• Using a variable that was never declared.
• Calling a method with the wrong number of arguments.
• Type mismatch like assigning a string to an integer variable.

Code Example:

int x = “hello”; // Type mismatch: String cannot be converted to int
System.out.println(y); // Variable y might not have been declared

2. Runtime Error

A runtime error occurs while the program is executing. The code compiled successfully, but something went wrong during actual operation due to unexpected conditions or invalid operations.

• When detected: During program execution, after compilation.
• Cause: Invalid operations, unexpected input, resource unavailability, or logic flaws.
• Fix: The programmer must add error handling, validate inputs, or fix logic.
• Program state: The program crashes or behaves unexpectedly mid-run.

Examples:

• Dividing a number by zero.
• Accessing an array index that does not exist.
• Trying to open a file that does not exist.
• Running out of memory during execution.

Code Example:

int[] arr = {1, 2, 3};
System.out.println(arr[5]); // ArrayIndexOutOfBoundsException

int result = 10 / 0; // ArithmeticException: Division by zero

Comparison Table: