Client-Server Model: Architecture, Protocols & Real-World Systems

TAKEAWAYS:

• The client-server model divides tasks between clients (requesters) and servers (providers) using request-response cycles over protocols like HTTP/HTTPS.
• Stateless vs. stateful servers: Stateless servers (e.g., HTTP) treat each request independently, while stateful servers (e.g., session-based apps) maintain client context.
• Protocols matter: HTTP for web, FTP for file transfers, SMTP for emails, and DNS for name resolution each define message formats and handshake rules.
• Scalability techniques: Load balancing (round-robin, least connections), caching (CDNs), and replication improve performance in high-demand systems like Daraz or NEPSE.
• Security risks: Client-server systems face threats like DDoS attacks, man-in-the-middle (MITM), and data breaches—mitigated by encryption (TLS), firewalls, and input validation.
• Real-world tie-ins: eSewa uses HTTPS for secure transactions, Pathao’s servers handle dynamic ride requests, and Ncell’s billing system relies on stateful session management.

Core Concepts: What Is the Client-Server Model?

The client-server model is a distributed computing architecture where:

• Clients (e.g., your laptop, smartphone) initiate requests (e.g., loading a webpage, sending an email).
• Servers (e.g., Google’s servers, eSewa’s backend) process requests and return responses.
• Communication happens over network protocols (rules for data exchange).

How It Works: A Step-by-Step Trace

sequenceDiagram
    participant Client as Client (e.g., Browser)
    participant Server as Server (e.g., Daraz Website)
    Client->>Server: 1. Request (HTTP GET /product/123)
    Server-->>Client: 2. Response (HTML + Product Data)
    Client->>Server: 3. Request (HTTP POST /cart/add)
    Server-->>Client: 4. Response (Confirmation + Updated Cart)
    Note over Client,Server: Stateless: Each request is independent.

Key Idea: The server does not remember past requests unless explicitly designed to (e.g., session cookies for logged-in users).

IMAGE: server rack in data center | A real server rack hosting multiple client-server applications (e.g., Ncell’s billing system, NEPSE’s stock data servers).

1. Client-Server Architecture Layers

The model can be visualized as three logical layers:

Real-World Example:

• eSewa App (Client) → eSewa Server (Application Layer) → Database (Data Layer).
• When you pay a bill, your phone (client) sends a request to eSewa’s server, which then queries the database to deduct the amount.

2. Protocols: How Clients and Servers Talk

Protocols define message formats, handshakes, and error handling. Three critical ones:

HTTP Request-Response Cycle (Worked Example)

When you visit daraz.com.np to buy a phone:

1. Your browser sends an HTTP GET request to Daraz’s server.
2. The server responds with:
   • Status code (e.g., 200 OK, 404 Not Found).
   • Headers (e.g., Content-Type: text/html).
   • Body (HTML page or JSON data).
3. The browser renders the page.

sequenceDiagram
    participant Browser as Your Browser
    participant Daraz as Daraz Server
    Browser->>Daraz: GET /phones?category=smartphones
    Daraz-->>Browser: 200 OK
    alt HTML Response
        Daraz-->>Browser: Headers: Content-Type: text/html
        Daraz-->>Browser: Body: <html>...</html>
    else JSON Response
        Daraz-->>Browser: Headers: Content-Type: application/json
        Daraz-->>Browser: Body: {"products": [...]}
    end
    Browser->>Daraz: POST /cart/add
    Daraz-->>Browser: 200 OK
    Daraz-->>Browser: Body: {"status": "added_to_cart"}

Why HTTPS?

• Encrypts data (e.g., your credit card details on Daraz) using TLS.
• Prevents MITM attacks (e.g., hackers intercepting your Khalti transaction).

3. Stateless vs. Stateful Servers: Key Differences

Worked Example: Ncell’s Billing System

• Stateless: When you check your balance via USSD (*123#), each request is independent.
• Stateful: When you log into the Ncell app, the server maintains your session to show your usage history.

4. Scalability: Handling Thousands of Clients

Servers must scale to handle traffic spikes (e.g., Dashain sales on Daraz or NEPSE trading hours). Techniques:

A. Load Balancing

Distributes requests across multiple servers to prevent overload. Methods:

• Round-Robin: Requests go to servers in turn (Server1 → Server2 → Server3 → ...).
• Least Connections: Sends requests to the server with the fewest active connections.

Real Example:

• Pathao’s servers use load balancing to handle ride requests during peak hours (e.g., 7–9 PM in Kathmandu).

B. Caching

Stores frequently accessed data (e.g., product listings on Daraz) to reduce server load.

• CDNs (Content Delivery Networks) cache content closer to users (e.g., Google’s global CDN).

C. Replication

Copies data across multiple servers to ensure high availability (e.g., Ncell’s backup servers).

5. Security Challenges and Solutions

Client-server systems face:

1. DDoS Attacks: Overwhelming servers with fake traffic (e.g., targeting NEPSE during market crashes).
   • Solution: Rate limiting, cloud-based DDoS protection (e.g., Cloudflare).
2. Man-in-the-Middle (MITM): Hackers intercepting unencrypted data (e.g., stealing Khalti OTPs).
   • Solution: HTTPS (TLS encryption).
3. SQL Injection: Malicious SQL queries (e.g., stealing Daraz customer data).
   • Solution: Prepared statements, input validation.

Worked Example: Secure eSewa Transaction

1. You enter your Khalti PIN.
2. The request is encrypted with TLS.
3. The server validates the PIN against its database (never stored in plaintext).
4. If valid, the transaction is processed; if not, a 403 Forbidden error is returned.

In the Real World

1. eSewa (Nepal)

   • Idea Used: Stateful server + HTTPS.
   • How: Maintains your session after login to track transactions. Uses TLS to encrypt payment data between your phone and eSewa’s servers.

2. Daraz (Nepal)

   • Idea Used: Load balancing + caching.
   • How: During Dashain sales, Daraz’s load balancer distributes requests across 100+ servers worldwide. Product pages are cached to speed up repeat visits.

3. Ncell’s Billing System

   • Idea Used: Stateless for USSD, stateful for app login.
   • How: USSD (*123#) is stateless—each balance check is independent. The Ncell app is stateful—your login session persists until you log out.

4. Google Search (Global)

   • Idea Used: DNS + CDN.
   • How: When you type google.com, DNS resolves the domain to Google’s nearest server. The CDN caches search results globally to reduce latency.

5. NEPSE Trading System

   • Idea Used: High-availability replication.
   • How: NEPSE’s servers replicate stock data across multiple locations to prevent crashes during volatile trading (e.g., budget announcements).

6. Designing a Client-Server System: Step-by-Step

Let’s design a simple online exam system (like TU’s internal exams) using the client-server model.

Requirements:

• Students submit answers via a web app.
• The server stores answers in a database.
• Results are generated after the exam ends.

Architecture:

Workflow:

1. Client (Student Browser) → Sends POST /submit with answers.
2. Server (Node.js/Python) → Validates input, stores in database.
3. Database (MySQL) → Records answers.
4. Result Generation Script → Runs after exam ends, calculates scores.

Security Considerations:

• Use HTTPS to encrypt submissions.
• Validate inputs to prevent SQL injection (e.g., student_id must be numeric).
• Rate-limit submissions to prevent cheating (e.g., 1 submission per minute).

Exam Tip

This unit is heavily tested in TU/PU exams with:

1. Diagram Questions (30%):

   • Draw a client-server interaction sequence (like the Daraz example above).
   • Sketch a load balancing setup or three-tier architecture.
   • Tip: Always label arrows with request/response types (e.g., HTTP GET, TLS Handshake).

2. Short Answer (40%):

   • Define stateless vs. stateful servers with examples (e.g., "Why is HTTP stateless?").
   • Explain one security risk (e.g., "How does MITM work?") and its solution.
   • Tip: Use real-world apps (e.g., "eSewa uses HTTPS to prevent...").

3. Problem Solving (30%):

   • Trace a protocol exchange: Given a scenario (e.g., "You visit daraz.com.np"), list the steps from DNS lookup to page load.
   • Design a system: "Design a client-server model for a traffic management app like Pathao." (Include layers, protocols, and scalability.)
   • Tip: Use bullet points for clarity. For example:

     1. Client: Pathao Mobile App (HTTP/HTTPS)
     2. Server: Pathao’s Load Balancer → Multiple App Servers
     3. Database: MongoDB for ride requests, user data
     4. Scalability: CDN for static maps, auto-scaling servers during peak hours.
     

Common Pitfalls to Avoid:

• Forgetting ports (e.g., HTTP is port 80, not 8080).
• Confusing stateless (HTTP) with stateful (sessions) without examples.
• Ignoring security in design questions (always mention encryption or validation).

Final Reminder: Exams love real-world ties. If asked about HTTP, mention Daraz’s HTTPS. If asked about scalability, mention Pathao’s load balancers. Visuals (sequence diagrams, architecture layers) double your marks.