7.0 Presentation Layers
Overview: OSI Layer Relationship
Application Layer | User Applications
Presentation Layer | Data Format, Encoding, Compression ← FOCUS
Session Layer | Dialogue Management, Negotiation ← FOCUS
Transport Layer | Reliable Data Transfer
Network Layer | Routing
Data Link Layer | Frame Transmission
Physical Layer | Bit Transmission
Layer Responsibilities Comparison
Aspect | Presentation Layer | Session Layer |
---|---|---|
Primary Role | Data format standardization | Dialogue management |
Key Functions | Format conversion, compression, encryption | Connection sync, negotiation |
Data Handling | Transforms data representation | Manages communication sessions |
Examples | JPEG, GIF, ASCII, EBCDIC | NetBIOS, RPC, SQL sessions |
Role of Presentation Layer
Core Functions: * Provides a standard format for transferred information * Overcomes compatibility problems between systems using dissimilar data representations and encoding rules * Handles aspects like data representation (how characters/data types are represented on different computers) * Specifies Media Types (Type, Subtype, Parameters) for defining data formats
Media Types Structure:
Media Type Format: Type/Subtype; Parameters
Examples:
- text/plain; charset=utf-8
- image/jpeg; quality=85
- video/mp4; codec=h264
- audio/mpeg; bitrate=320kbps
Role of Session Layer
Core Functions: * Manages the dialogue between systems * Includes connection synchronization and negotiation * Note: Detailed session management might be less of a focus
Content Negotiation Process
Purpose: Ensure that the sender and receiver agree on data formats and encoding schemes (e.g., codecs for multimedia)
Two-Stage Offer/Answer Model
Sender Receiver
| |
| 1. Offer (Propose) |
| ─────────────────────> |
| Supported formats |
| |
| 2. Answer (Select) |
| <───────────────────── |
| Chosen format |
| |
| 3. Data Transfer begins |
| ─────────────────────> |
Comparison: Content Negotiation vs TCP Handshake
Aspect | Content Negotiation | TCP Three-Way Handshake |
---|---|---|
Steps | 2 steps (Offer/Answer) | 3 steps (SYN/SYN-ACK/ACK) |
Purpose | Data format agreement | Connection establishment |
Layer | Presentation/Session | Transport |
Third Step | Not needed | Required for reliability |
Reason for difference | Lower layers handle reliability | Must ensure connection state |
Key Insight: Unlike the TCP three-way handshake, content negotiation does not typically involve a third acknowledgment step, as reliable data transfer and connection establishment are handled by lower layers like the Transport Layer. This separation of concerns is a benefit of layering.
Example Protocol: Session Description Protocol (SDP) is used for describing multimedia sessions and specifying media types and parameters.
Compression Overview
Motivation for Data Compression
Benefits Hierarchy:
Data Compression
├── Primary Benefits
│ ├── Reducing data volume
│ ├── Saving bandwidth
│ └── Faster transfer
└── Secondary Benefits
├── Less memory for intermediate node buffers
├── Lower cost
└── Less packets to be handled (goes faster)
Optimal Compression Location
Best Practice: Sender compresses, and the receiver decompresses
Why not at intermediate nodes? * Adds complexity * Wastes time/resources * Violates end-to-end principle
Sender ──[Compress]──> Network ──[No Processing]──> Receiver ──[Decompress]──>
↑ ↑ ↑
Efficient Transparent Efficient
Types of Compression Comparison
Criteria | Lossy Compression | Lossless Compression |
---|---|---|
Data Preservation | Loses data during compression | Preserves original data |
Use Case | Exact original data isn't critical | Exact original data is critical |
Common Applications | Multimedia (images, videos, audio) | Text, executable files, documents |
Human Perception | Slight loss may not be noticeable | Must be bit-perfect |
Compression Ratio | Higher (more compression) | Lower (less compression) |
Reversibility | Irreversible | Completely reversible |
Application Examples
Lossy Compression: * JPEG images (photography) * MP3 audio (music) * MP4 video (streaming) * WebP images (web)
Lossless Compression: * ZIP files (archives) * PNG images (graphics with text) * FLAC audio (high-quality music) * Huffman coding (text)
Huffman Coding: Detailed Analysis
Key Characteristics
- A frequency-dependent lossless compression technique
- Method for constructing a variable-length code
- Assigns shorter codes to more frequently used characters
- Uses a greedy algorithm to build a binary tree (Huffman tree)
- Builds tree by repeatedly combining the two smallest frequencies
- The resulting code is a prefix code (no code word is a prefix of another)
Huffman Coding Algorithm Visualization
Step-by-Step Process:
- Count character frequencies
- Create leaf nodes for each character
- Build tree using greedy approach
- Assign binary codes (0 = left, 1 = right)
Worked Example: Huffman Coding Calculation
Given text: "AABBBCCCCDDDD"
Step 1: Frequency Count
Character | Frequency | Probability
A | 2 | 2/13 ≈ 0.15
B | 3 | 3/13 ≈ 0.23
C | 4 | 4/13 ≈ 0.31
D | 4 | 4/13 ≈ 0.31
Step 2: Build Huffman Tree
Initial: A(2) B(3) C(4) D(4)
Iteration 1: Combine A(2) + B(3) = AB(5)
Remaining: AB(5) C(4) D(4)
Iteration 2: Combine C(4) + D(4) = CD(8)
Remaining: AB(5) CD(8)
Iteration 3: Combine AB(5) + CD(8) = Root(13)
Final Tree:
Root(13)
/ \
AB(5) CD(8)
/ \ / \
A(2) B(3) C(4) D(4)
Step 3: Assign Codes
Character | Huffman Code | Path from Root
A | 00 | Left → Left
B | 01 | Left → Right
C | 10 | Right → Left
D | 11 | Right → Right
Step 4: Compression Calculation
Original encoding (2 bits per character): 13 × 2 = 26 bits
Huffman encoding: * A: 2 × 2 bits = 4 bits * B: 3 × 2 bits = 6 bits
C: 4 × 2 bits = 8 bits * D: 4 × 2 bits = 8 bits * Total: 26 bits*
Compression Ratio: 26/26 = 1.0 (no compression in this balanced case)
Prefix Code Property
Why prefix codes matter:
Valid Prefix Code: Invalid (ambiguous):
A = 0 A = 0
B = 10 B = 01
C = 11 C = 011
Decoding "0110": Decoding "0110":
0-11-0 = A-C-A Multiple possibilities:
✓ Unambiguous 0-1-1-0 or 01-1-0 or 011-0
✗ Ambiguous
Huffman vs Fixed-Length Comparison
Aspect | Fixed-Length | Huffman Coding |
---|---|---|
Code Length | Same for all characters | Variable based on frequency |
Efficiency | Suboptimal for skewed frequencies | Optimal for given frequencies |
Decoding | Simple indexing | Requires tree traversal |
Storage | No tree needed | Must store/transmit tree |
Best Case | Uniform distribution | Highly skewed distribution |
Summary: Knowledge Connections
Layer Integration
Session Layer ←→ Content Negotiation ←→ Presentation Layer
↓ ↓ ↓
Dialogue Mgmt Format Agreement Data Transform
↓ ↓ ↓
SDP Offer/Answer Compression
Compression Decision Tree
Data to Compress?
├── Critical Accuracy Required?
│ ├── YES → Lossless (e.g., Huffman)
│ └── NO → Check data type
└── Multimedia Content?
├── YES → Lossy (JPEG, MP3)
└── NO → Lossless (ZIP, PNG)
These notes demonstrate the interconnected nature of presentation and session layer concepts, showing how content negotiation bridges session management with data formatting, and how compression techniques serve different data preservation requirements.