8.0 Client and Server
This section covers the design and architecture of client-server systems, drawing on concepts from distributed systems.
Architecture Comparison Overview
| Architecture Type | Primary Focus | Communication Model | Service Discovery | Scalability Approach |
|---|
| Client-Server | Entity interaction | Asymmetric (Client initiates) | Known server locations | Add more servers |
| Peer-to-Peer | Equal entities | Symmetric | Distributed discovery | Add more peers |
| SOA | Service provisioning | Request-response | Registry-based | Service composition |
Key Distributed System Characteristics Matrix
| Characteristic | Client-Server | SOA | Impact on Design |
|---|
| Resource Sharing | Server-centric | Service-centric | Determines allocation strategy |
| Openness | Moderate | High | Affects vendor independence |
| Concurrency | Server-managed | Service-managed | Influences performance design |
| Scalability | Horizontal server scaling | Service composition | Guides growth strategy |
| Fault Tolerance | Server redundancy | Service alternatives | Shapes reliability approach |
1. Introduction to Distributed Systems
- Virtually all large computer-based systems today are distributed systems.
- Information processing is spread across multiple computers.
- Different architectures exist, including client-server, peer-to-peer, and service-oriented architectures.
Core Characteristics Analysis
| Characteristic | Definition | Implementation Challenge | Real-world Example |
|---|
| Resource Sharing | Maximizing utility and minimizing cost | Network-level concurrent access complexity | Cloud computing, shared memory, disk space |
| Openness | Multi-vendor equipment/software compatibility | Standardization and interoperability | Mixed OS environments, cross-platform APIs |
| Concurrency | Simultaneous processing capability | Synchronization and coordination | Parallel job processing, multi-threading |
| Scalability | Dynamic resource adjustment | Load balancing and resource management | Auto-scaling cloud services |
| Fault Tolerance | Continued operation after failures | Redundancy and failover mechanisms | Service migration, backup systems |
Middleware Requirements
Distributed System Components
├── Application Layer
├── Middleware Layer
│ ├── Transaction Monitors
│ ├── Data Converters
│ └── Communication Controllers
└── Network Infrastructure
- Middleware software (like transaction monitors, data converters, communication controllers) may be needed to manage and support components in a distributed system.
2. Client-Server Architecture
- A primary distributed systems architecture.
- Consists of a set of servers that provide specific services (like printing, data management) and a set of clients that call on these services.
Architecture Flow Diagram
[Client 1] ──request──► [Server A: Database]
[Client 2] ──request──► [Server B: Web Service]
[Client 3] ──request──► [Server C: File Storage]
│ │
└──response◄──────────────┘
Key Properties Analysis
| Property | Description | Design Implication |
|---|
| Asymmetric Relationship | Clients initiate, servers respond | Connection management strategy |
| Server Awareness | Clients know servers, not vice versa | Service discovery mechanisms |
| Role Specialization | UI vs. Data/Logic separation | Resource allocation decisions |
| Resource Sharing | Many-to-few client-server ratio | Load balancing requirements |
Specialization Breakdown
| Component | Responsibility | Optimization Focus |
|---|
| Client | User Interface (GUI, rendering) | User experience, responsiveness |
| Server | Data management, application logic | Performance, reliability, security |
Real-world Implementation Examples
| Service Type | Architecture Components | Scalability Pattern |
|---|
| Streaming Video | Video server + Web server + Catalog server | Content delivery networks |
| Online Gaming | Game logic server + Image server + Database | Geographic distribution |
| Email System | Email server + Authentication + Storage | Server clustering |
| Chat Application | Chat server + User management + Message store | Horizontal scaling |
3. Advantages and Disadvantages Analysis
Comparative Trade-offs
| Aspect | Advantages | Disadvantages | Mitigation Strategy |
|---|
| Data Distribution | Straightforward implementation | No shared data model | Standardized APIs |
| Network Utilization | Effective use of network systems | Potential bottlenecks | Load balancing |
| Hardware Costs | Cheap commodity hardware | Redundant management overhead | Centralized management tools |
| Scalability | Easy server addition/upgrade | Lack of central service registry | Service discovery protocols |
Cost-Benefit Matrix
High Benefit, Low Cost │ High Benefit, High Cost
─────────────────────────┼──────────────────────────
• Data distribution │ • Network optimization
• Hardware flexibility │ • Advanced load balancing
─────────────────────────┼──────────────────────────
Low Benefit, Low Cost │ Low Benefit, High Cost
─────────────────────────┼──────────────────────────
• Basic implementations │ • Over-engineered solutions
• Simple protocols │ • Unnecessary redundancy
4. Layered Architectures in Client-Server
Architecture Evolution Comparison
| Architecture | Layers | Distribution | Complexity | Performance | Management |
|---|
| Two-Tier | 2 | Client-Server | Low | Variable | Simple |
| Three-Tier | 3 | Client-App-Data | Medium | Optimized | Balanced |
| N-Tier | N | Distributed | High | Scalable | Complex |
Two-Tier Architecture Models
Model Comparison Table
| Model | Client Responsibilities | Server Responsibilities | Use Case | Performance Profile |
|---|
| Thin Client | Presentation only | Application + Data | IoT, terminals | Low client load |
| Fat Client | Presentation + Application | Data Management | Desktop apps | High client utilization |
Processing Load Distribution
Thin Client Model:
Client: [████] 20% (UI only)
Server: [████████████████] 80% (Logic + Data)
Fat Client Model:
Client: [████████████] 60% (UI + Logic)
Server: [████████] 40% (Data only)
Three-Tier Architecture Breakdown
Tier 1: Presentation Layer
├── Web Browser
├── Mobile App
└── Desktop Client
Tier 2: Application Processing Layer
├── Business Logic Server
├── API Gateway
└── Authentication Service
Tier 3: Data Management Layer
├── Database Server
├── File Storage
└── Cache Systems
| Metric | Two-Tier Thin | Two-Tier Fat | Three-Tier | Explanation |
|---|
| Network Traffic | High | Medium | Optimized | Logic placement affects data flow |
| Client Resource Usage | Low | High | Medium | Processing distribution impact |
| Scalability | Limited | Poor | Excellent | Independent layer scaling |
| Maintenance | Simple | Complex | Balanced | Separation of concerns |
Real-world Example: Banking System
Three-Tier Banking Architecture:
Presentation (Client):
• Mobile banking app
• Web browser interface
• ATM interface
Application Processing (Server):
• Account management service
• Transaction processing
• Security validation
• Business rule enforcement
Data Management (Server):
• Customer database
• Transaction history
• Account balances
• Audit logs
Calculation Example: Server Load Distribution
Scenario: 1000 concurrent users, 3-tier architecture
Load Distribution Calculation:
Presentation Tier (Client-side):
• UI rendering: 1000 clients × 10% CPU = Local processing
• Network requests: 1000 × 5 requests/min = 5000 requests/min
Application Tier:
• Request processing: 5000 requests/min ÷ 3 servers = 1667 requests/server/min
• Business logic: 60% of total processing load
Data Tier:
• Database queries: 5000 requests/min × 0.8 DB ratio = 4000 queries/min
• Storage I/O: 40% of total processing load
5. Service-Oriented Architecture (SOA)
SOA vs Client-Server Paradigm Shift
| Dimension | Client-Server | SOA | Key Difference |
|---|
| Primary Focus | Entity interaction | Service provisioning | Relationship vs. Function |
| Discovery Model | Known endpoints | Registry-based | Static vs. Dynamic |
| Service Binding | Compile-time | Runtime (potential) | Fixed vs. Flexible |
| Resource Model | Server ownership | Service consumption | Ownership vs. Usage |
| Scalability | Server addition | Service composition | Hardware vs. Logic |
SOA Component Architecture
SOA Interaction Flow:
1. Service Provider ──publishes──► Service Registry
│
2. Service Requester ──discovers──────┘
│
3. └──requests service──► Service Provider
│
4. ◄──service response─────┘
Service Characteristics Matrix
| Characteristic | Impact | Implementation | Benefit |
|---|
| Provider Independence | Vendor flexibility | Standard interfaces | Reduced lock-in |
| Runtime Service Finding | Dynamic discovery | Registry protocols | Adaptive systems |
| Service Composition | Modularity | API orchestration | Rapid development |
| Pay-per-use Model | Cost optimization | Usage metering | Resource efficiency |
| Compact Applications | Reduced complexity | Microservices | Maintainability |
| Reactive/Adaptive | Dynamic behavior | Event-driven design | Responsiveness |
Hybrid Implementation Example
E-commerce Platform: SOA + Client-Server Hybrid
Client-Server Components:
├── Web Frontend (Client)
├── Application Server
└── Database Server
SOA Services:
├── Payment Processing Service (External)
├── Shipping Calculation Service (External)
├── Inventory Management Service (Internal)
└── User Authentication Service (Shared)
Service Registry:
• API Gateway managing service discovery
• Load balancing across service instances
• Health monitoring and failover
| Architecture | Setup Cost | Operating Cost | Flexibility | Performance |
|---|
| Pure Client-Server | Low | Medium | Low | High |
| Pure SOA | High | Variable | High | Variable |
| Hybrid Approach | Medium | Medium | High | Optimized |
Calculation Example: SOA Service Costs
Scenario: E-commerce platform with SOA services
Monthly Service Cost Calculation:
Internal Services (Fixed costs):
• User Management: $500/month
• Inventory System: $800/month
• Order Processing: $600/month
Total Internal: $1,900/month
External Services (Usage-based):
• Payment Processing: $0.30 per transaction
• Shipping API: $0.05 per lookup
• Email Service: $0.001 per email
Usage Example (10,000 transactions/month):
• Payment: 10,000 × $0.30 = $3,000
• Shipping: 10,000 × $0.05 = $500
• Email: 15,000 × $0.001 = $15
Total External: $3,515/month
Total SOA Cost: $1,900 + $3,515 = $5,415/month
Traditional equivalent infrastructure: $8,000/month
Cost saving: $2,585/month (32% reduction)
Architecture Decision Framework
| Factor | Client-Server Best | SOA Best | Hybrid Recommended |
|---|
| Project Size | Small-Medium | Large-Enterprise | Medium-Large |
| Team Expertise | Traditional IT | DevOps/Cloud | Mixed skills |
| Budget Constraints | Limited upfront | Flexible operating | Balanced approach |
| Change Frequency | Stable requirements | Dynamic needs | Moderate changes |
| Integration Needs | Internal systems | External partners | Mixed requirements |
Exam-Focused Summary
Critical Decision Points for Concept Questions
Architecture Selection Criteria
| Requirement | Recommended Architecture | Justification |
|---|
| Low latency, high performance | Fat Client (2-tier) | Local processing reduces network overhead |
| Centralized data control | Thin Client (2-tier) | All logic and data on server |
| Independent scaling needs | Three-tier | Separate scaling of presentation, logic, data |
| External service integration | SOA | Registry-based discovery and composition |
| Limited client resources | Thin Client | Minimal client-side requirements |
| Offline capability needed | Fat Client | Local processing when disconnected |
Network Load Calculation
Total Network Traffic = (Requests/second) × (Average Request Size) × (Number of Clients)
Thin Client: High network traffic (all processing remote)
Fat Client: Lower network traffic (local processing)
Three-tier: Optimized traffic (processing layer filters requests)
Scalability Metrics
Scalability Factor = (Max Supported Users) / (Min Infrastructure Cost)
Client-Server: Linear scaling (add servers)
SOA: Exponential scaling (service composition)
Cost-Benefit Analysis
TCO = Infrastructure Cost + Development Cost + Maintenance Cost + Operating Cost
ROI = (Benefits - Total Costs) / Total Costs × 100%
Common Exam Scenarios
Scenario 1: Mobile Banking App
Question: Choose appropriate architecture for 100, 000 concurrent users
Analysis: * High security requirements → Server-side processing * Mobile devices → Limited resources * Scalability critical → Independent layer scaling
Answer: Three-tier architecture * Mobile app (Presentation) * API server cluster (Application) * Database cluster (Data)
Question: Minimize latency for competitive gaming
Analysis: * Ultra-low latency required → Local processing * Rich graphics → Client-side rendering * Game state synchronization → Server coordination
Answer: Fat Client architecture * Game engine on client * State sync server * Optimized network protocols
Question: Connect 50+ diverse systems
Analysis: * Multiple vendors → Standard interfaces needed * Dynamic service requirements → Runtime discovery * Cost optimization → Pay-per-use model
Answer: SOA architecture * Service registry for discovery * API gateway for integration * Microservices for modularity
Load Distribution (Three-tier)
Client Load = UI Processing + User Interaction
Application Server Load = Business Logic + API Processing
Database Load = Query Processing + Data Storage
Total System Load = Sum of all tier loads
Bottleneck Tier = Tier with highest utilization ratio
Service Cost Optimization (SOA)
Service Cost = Fixed Cost + (Usage × Variable Rate)
Total SOA Cost = Σ(Individual Service Costs)
Break-even Point = Fixed Infrastructure Cost / Monthly SOA Savings
Fault Tolerance Calculation
System Availability = Π(Individual Component Availability)
MTBF (Mean Time Between Failures) = 1 / Failure Rate
Recovery Time = Detection Time + Switchover Time + Sync Time