跳转至

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

AspectPresentation LayerSession Layer
Primary RoleData format standardizationDialogue management
Key FunctionsFormat conversion, compression, encryptionConnection sync, negotiation
Data HandlingTransforms data representationManages communication sessions
ExamplesJPEG, GIF, ASCII, EBCDICNetBIOS, 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

AspectContent NegotiationTCP Three-Way Handshake
Steps2 steps (Offer/Answer)3 steps (SYN/SYN-ACK/ACK)
PurposeData format agreementConnection establishment
LayerPresentation/SessionTransport
Third StepNot neededRequired for reliability
Reason for differenceLower layers handle reliabilityMust 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

CriteriaLossy CompressionLossless Compression
Data PreservationLoses data during compressionPreserves original data
Use CaseExact original data isn't criticalExact original data is critical
Common ApplicationsMultimedia (images, videos, audio)Text, executable files, documents
Human PerceptionSlight loss may not be noticeableMust be bit-perfect
Compression RatioHigher (more compression)Lower (less compression)
ReversibilityIrreversibleCompletely 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:

  1. Count character frequencies
  2. Create leaf nodes for each character
  3. Build tree using greedy approach
  4. 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

AspectFixed-LengthHuffman Coding
Code LengthSame for all charactersVariable based on frequency
EfficiencySuboptimal for skewed frequenciesOptimal for given frequencies
DecodingSimple indexingRequires tree traversal
StorageNo tree neededMust store/transmit tree
Best CaseUniform distributionHighly 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.