Connection-Oriented vs Connectionless Services

Imagine sending a postcard. You write your message, add the recipient's address, hand it to the postal service, and... walk away. You receive no confirmation that the postcard arrived. You cannot know if it was lost, delayed, or delivered but never read. Each postcard is an independent entity—the postal service neither knows nor cares whether it's related to any previous or future mailings.

This is connectionless communication in its purest form. Where connection-oriented services establish elaborate contracts before exchanging data, connectionless services embrace radical simplicity: send a message, include the destination, and let the network do its best. No handshakes. No state maintenance. No guarantees.

Far from being a primitive remnant of early networking, connectionless service represents a deliberate architectural choice with profound implications. It powers DNS (the Internet's directory), real-time gaming, video conferencing, streaming media, and countless IoT applications. Understanding connectionless service is essential for selecting the right transport for each application—and for appreciating why the transport layer offers both paradigms.

Connectionless communication embodies a fundamentally different philosophy than its connection-oriented counterpart. Rather than establishing relationships, it embraces transaction independence. Each message (datagram) is self-contained—carrying all information needed for delivery—and is treated independently by the transport layer.

The datagram paradigm:

A datagram is a self-contained unit of data that includes:

• Source and destination addresses (IP addresses at the network layer)
• Source and destination port numbers (at the transport layer)
• The payload (application data)
• A minimal header with essential metadata (length, checksum)

Unlike connection-oriented streams where data flows in a continuous, ordered pipe, datagrams are discrete packets that may:

• Arrive in any order
• Arrive multiple times (duplicates)
• Not arrive at all (lost)
• Be delivered to multiple recipients (multicast/broadcast)

The transport layer makes no attempt to correct these behaviors. It simply provides access to the underlying network service with minimal overhead.

The end-to-end argument:

Connectionless transport aligns with the end-to-end argument in network design—a foundational principle stating that certain functions should be implemented at endpoints rather than within the network. The argument states:

Functions placed at low levels of a system may be redundant or of little value when compared to the cost of providing them at that low level.

For connectionless service, this means:

1. The network provides basic delivery: Best-effort forwarding of datagrams
2. Applications provide what they need: Reliability, ordering, or neither—as required
3. No wasted functionality: Applications that don't need guarantees don't pay for them

Consider a DNS query: a single question expects a single answer. If the answer doesn't arrive, the application simply resends the question. Building connection overhead into this exchange would double or triple the packets required—all for a transaction completed in one round-trip.

Speed through simplicity:

Connectionless protocols are fast precisely because they do so little:

• No connection setup latency
• No acknowledgment processing
• No retransmission logic
• No ordering buffers
• No flow control overhead

The application sends data, that data becomes a datagram, and the datagram is dispatched to the network. The entire process adds perhaps 10-20 microseconds. Compare this to TCP's multi-millisecond handshake, and you understand why latency-sensitive applications gravitate toward connectionless transport.

User Datagram Protocol (UDP) is the Internet's canonical connectionless transport protocol. Defined in RFC 768 (August 1980), UDP's specification fits on three pages—a testament to its simplicity. Despite (or because of) this minimalism, UDP carries a substantial fraction of Internet traffic.

The UDP header:

UDP's header is brilliantly minimal—just 8 bytes:

 0      7 8     15 16    23 24    31
+--------+--------+--------+--------+
|  Source Port    |   Dest Port     |
+--------+--------+--------+--------+
|    Length       |    Checksum     |
+--------+--------+--------+--------+
|            Data (payload)         |
+--------+--------+--------+--------+

• Source Port (16 bits): Identifies the sending application process. Optional for replies.
• Destination Port (16 bits): Identifies the receiving application process. Required.
• Length (16 bits): Total datagram length (header + data). Minimum 8 bytes.
• Checksum (16 bits): Error detection for header and data. Optional in IPv4, mandatory in IPv6.

That's it. No sequence numbers. No acknowledgment fields. No flags. No window sizes. Just addressing and minimal error detection.

What UDP provides:

1. Multiplexing/demultiplexing: Port numbers allow multiple applications to share a single IP address
2. Checksumming: Optional error detection (mandatory in IPv6)
3. Message boundaries: Each send() produces exactly one datagram; each recv() receives exactly one datagram

What UDP does not provide:

• Reliability (no retransmission)
• Ordering (datagrams may arrive out of sequence)
• Flow control (sender cannot overwhelm receiver... or can)
• Congestion control (sender may overwhelm network)
• Connection establishment or teardown

UDP's role in the protocol stack:

UDP sits between IP (network layer) and applications (application layer). Its job is simply to add port-based multiplexing to IP's host-to-host delivery:

┌─────────────────────────────────────┐
│        Application (e.g., DNS)     │
├─────────────────────────────────────┤
│      UDP (ports, checksum)          │  ← Connectionless transport
├─────────────────────────────────────┤
│        IP (routing, addressing)     │
├─────────────────────────────────────┤
│     Network Interface (frames)      │
└─────────────────────────────────────┘

UDP is sometimes called a "thin shim" over IP—adding just enough functionality (ports) to enable application-level communication while exposing IP's best-effort semantics.

The UDP programming model:

Unlike TCP sockets, which represent connections, UDP sockets represent endpoints. The API reflects this:

// Create socket
int sock = socket(AF_INET, SOCK_DGRAM, 0);

// Optionally bind to local port
bind(sock, &local_addr, sizeof(local_addr));

// Send datagram (specify destination each time)
sendto(sock, buffer, len, 0, &dest_addr, sizeof(dest_addr));

// Receive datagram (learn source from each packet)
recvfrom(sock, buffer, len, 0, &src_addr, &addr_len);

Note: no connect(), listen(), or accept(). Each sendto() can target a different destination. Each recvfrom() can receive from anyone.

The defining characteristic of connectionless service is statelessness—the transport layer maintains no per-session state. Each datagram is processed independently, with no memory of past or future datagrams. This has profound implications for both protocol behavior and system design.

No per-connection resources:

A TCP server with 10,000 clients maintains 10,000 TCBs (Transmission Control Blocks), each consuming memory for sequence numbers, windows, timers, and buffers. A UDP server with 10,000 clients maintains... nothing. The same UDP socket can receive from any source without prior arrangement.

This asymmetry explains why UDP servers scale to massive levels with minimal resources:

• DNS root servers: Handle 100,000+ queries per second—each from a different client
• Game servers: Manage thousands of players with one socket per game instance
• Streaming servers: Multicast to millions of receivers without per-receiver state

Implications of statelessness:

1. No session concept

UDP has no notion of a "session" spanning multiple exchanges. If an application needs sessions, it must implement them:

• Session tokens in application data
• Sequence numbers in application protocol
• Timeout logic in application code

2. Source address may be spoofed

Without a handshake to verify the source can receive responses, UDP source addresses can be forged. This enables:

• Amplification attacks: Small queries elicit large responses to spoofed victims
• IP spoofing: Attacker impersonates another host

TCP's three-way handshake verifies that the source can receive (it must respond to SYN-ACK). UDP provides no such verification.

3. No built-in timeout or keepalive

TCP connections can detect peer failure through keepalives and timeout expiration. UDP provides no such mechanism. If a peer disappears, the sender will continue transmitting into the void unless the application implements its own health checking.

4. No ordering or reliability by default

Applications using UDP must decide:

• Do we care about ordering? If yes, add sequence numbers.
• Do we care about reliability? If yes, add acknowledgments and retransmission.
• Do we care about duplicates? If yes, add duplicate detection.

This shifts complexity to the application layer—which may be exactly where it belongs if application-specific handling is needed.

When statelessness is advantageous:

Despite the challenges, statelessness provides concrete benefits:

1. Server resilience: Servers can restart without breaking clients. There's no state to lose.
2. Load balancing: Datagrams can be distributed across servers without session affinity.
3. Scalability: Resources scale with work, not connections. Idle clients cost nothing.
4. Simplicity: No complex state machines, timers, or cleanup logic.

For request-response protocols (DNS, DHCP, SNMP) and loss-tolerant streaming applications (voice, video, gaming), statelessness is not a limitation—it's the correct design.

A crucial distinction between connectionless and connection-oriented services lies in how they handle application data units. UDP preserves message boundaries; TCP presents a byte stream. This difference has significant implications for application design.

TCP's byte stream abstraction:

TCP treats data as a continuous stream of bytes with no inherent structure:

• write(500 bytes) followed by write(500 bytes) → stream of 1000 bytes
• read(1000 bytes) might receive 1000 bytes, or 700, or 300—whatever has arrived
• Application must implement framing (delimiters, length prefixes) to recover messages

UDP's message preservation:

UDP maintains a one-to-one correspondence between send operations and datagrams:

• sendto(500 bytes) produces exactly one 500-byte datagram
• recvfrom() receives exactly that 500-byte datagram (if it arrives)
• Each send is atomic—either the entire message arrives or nothing does

This message-oriented behavior simplifies protocols where messages are discrete units:

• DNS queries and responses
• Game state updates
• Telemetry samples
• RPC calls

Implications for application design:

Message size limits:

UDP datagrams have size constraints:

• Maximum UDP datagram: 65,535 bytes (16-bit length field)
• Practical limit: MTU constraints (typically 1472 bytes for Ethernet without fragmentation)
• Exceeding MTU causes IP fragmentation, which is problematic (loss of one fragment requires retransmission of entire datagram)

Large messages must be fragmented at the application layer and reassembled—effectively re-implementing what TCP does automatically.

Atomic delivery:

UDP atomicity is a double-edged sword:

• Advantage: No partial messages—receive the whole thing or nothing
• Disadvantage: Large datagrams may be lost due to fragmentation issues

No stream accumulation:

With TCP, slow sends accumulate in the stream—receivers can process at their own pace. With UDP:

• Receive buffer fills with whole datagrams
• If buffer overflows, datagrams are silently dropped
• No backpressure to sender—they keep sending

This makes UDP unsuitable for bulk data transfer where sender may outpace receiver.

Protocol design considerations:

UDP-based protocols typically:

• Define fixed maximum message sizes that fit in one MTU
• Include sequence numbers if ordering matters
• Include length or self-delimiting formats within payloads
• Implement application-level acknowledgment if needed

UDP offers best-effort delivery—the same service model as IP itself. The transport layer makes no attempt to recover from network failures. If a packet is lost, duplicated, or delivered out of order, the application must cope.

What "best-effort" means:

1. Loss is possible and unreported: Datagrams may vanish in the network—router buffer overflow, link failure, corruption—without notification to sender or receiver.

2. Duplication is possible: Network conditions (routing loops, retransmission by lower layers) can cause the same datagram to arrive multiple times.

3. Reordering is possible: Datagrams may take different paths with different latencies, arriving in a different order than sent.

4. Corruption is possible: The UDP checksum can detect errors but not correct them. Corrupted datagrams are silently discarded.

5. No flow control: The sender may transmit faster than the receiver can process. Overflow means loss.

6. No congestion control: The sender may transmit faster than the network can forward. Overflow means loss for everyone.

Why best-effort is acceptable:

For many applications, perfect reliability is neither required nor desirable:

Real-time media (VoIP, video):

• A retransmitted packet arriving 300ms late is useless—the audio moment has passed
• Playing a slightly corrupted frame is better than freezing while awaiting retransmission
• Loss concealment (interpolation) handles occasional drops better than retransmission

Query-response protocols (DNS, DHCP):

• Simple timeout + retry is sufficient reliability
• Connection overhead would dominate for single-exchange transactions
• Idempotent queries can be resent without side effects

High-frequency telemetry:

• Sensors sending 100 samples/second can tolerate occasional loss
• The next sample arrives in 10ms anyway
• Retransmitting stale data wastes bandwidth

Gaming:

• Game state is constantly updating; old states become irrelevant
• Low latency more important than completeness
• Client-side prediction masks brief data gaps

Building reliability over UDP:

When applications need reliability but reject TCP's approach (perhaps to eliminate head-of-line blocking or customize retransmission), they can build reliability mechanisms over UDP:

Application-level retransmission:

• Sender maintains retry timers per message
• Receiver sends acknowledgments
• Lost messages are retransmitted after timeout

Forward Error Correction (FEC):

• Redundant data allows reconstruction without retransmission
• Trade bandwidth for latency
• Used in video streaming (e.g., WebRTC)

Selective reliability:

• Critical data (keyframes, control messages) gets retransmission
• Non-critical data (delta updates) is best-effort

QUIC exemplifies this approach: UDP-based, but with encryption, multiplexed streams, and selective reliability per stream—avoiding TCP's head-of-line blocking while providing guarantees where needed.

A unique capability of connectionless service is native support for multicast and broadcast communication. TCP, being connection-oriented, is inherently point-to-point—a connection exists between exactly two endpoints. UDP, with no connection concept, can address multiple recipients simultaneously.

Broadcast:

Broadcast sends a datagram to all hosts on a local network segment:

• Limited broadcast (255.255.255.255): Delivered to all hosts on the local network; never forwarded by routers
• Directed broadcast (e.g., 192.168.1.255): Targets all hosts in a specific subnet; may cross routers (though often blocked for security)

Use cases:

• DHCP discovery: Client broadcasts to find DHCP servers
• ARP: Resolving IP addresses to MAC addresses
• Service discovery: Finding devices on local network

Multicast:

Multicast sends a datagram to a specific group of interested hosts:

• Group address (224.0.0.0 – 239.255.255.255): Identifies the multicast group
• Receivers join groups: Using IGMP (Internet Group Management Protocol)
• Routers forward selectively: Only to network segments with group members
• Single transmission, multiple receivers: Efficient for one-to-many communication

Why multicast requires connectionless transport:

Consider streaming a live video to 10,000 viewers:

Unicast approach (TCP or UDP):

• Server maintains 10,000 individual streams
• Transmits 10,000 copies of each packet
• Enormous bandwidth and CPU consumption

Multicast approach (UDP only):

• Server transmits one stream to multicast group
• Network replicates packets at branch points
• Bandwidth consumption independent of viewer count

TCP cannot multicast because:

1. Connections are point-to-point
2. Each connection has unique sequence numbers
3. Reliability semantics (all receivers must ACK) are unscalable

UDP naturally supports multicast because:

1. Datagrams are independent—no connection state
2. Best-effort delivery—no ACKs to aggregate
3. Message-oriented—each datagram is self-contained

Real-world multicast applications:

• IPTV: Television distribution over IP networks
• Financial market data: Stock tickers to trading floors
• Software updates: Distributing patches to many machines simultaneously
• Video conferencing: Efficient many-to-many communication
• Routing protocols: OSPF uses multicast for hello packets

UDP's checksum provides the sole reliability mechanism at the transport layer—and even this is optional in IPv4. Understanding how UDP checksums work reveals both their value and their limitations.

The UDP checksum calculation:

The UDP checksum covers:

1. Pseudo-header: Source IP, destination IP, protocol number, UDP length (borrowed from IP layer)
2. UDP header: Source port, destination port, length, checksum (set to 0 during calculation)
3. UDP payload: The application data

The checksum algorithm:

1. Treat the data as 16-bit words
2. Sum all words using one's complement arithmetic
3. Take the one's complement of the sum
4. Store in the checksum field

At the receiver:

1. Sum all words (including checksum)
2. If result is all ones (0xFFFF), data is intact
3. Otherwise, discard the datagram

Why include a pseudo-header?

The pseudo-header ensures that datagrams are delivered to the correct destination. Without it:

• A corrupted destination IP might deliver data to wrong host
• The receiver, trusting the UDP header alone, would accept it
• Data would reach the wrong application

By including IP addresses in the checksum, such corruption is detected.

Checksum optionality:

IPv4: The UDP checksum is optional. A value of 0 indicates no checksum was computed. This was acceptable when lower layers (Ethernet CRC) provided error detection, and processing power was limited.

IPv6: The UDP checksum is mandatory. IPv6's own header has no checksum, so transport-layer checksums are essential.

Checksum limitations:

The UDP checksum is a simple error-detecting mechanism with known weaknesses:

• Detects most single-bit errors: One-bit flips are caught
• Detects most burst errors: Short error bursts typically detected
• May miss certain error patterns: Some multi-bit errors can produce valid checksums
• Probability of undetected error: Roughly 1 in 65,536 for random corruption

For high-integrity applications, additional mechanisms (CRC, cryptographic hashes, application checksums) may be warranted.

Performance considerations:

Computing checksums consumes CPU cycles:

• Software checksum: ~1 cycle per byte on modern CPUs
• Hardware offload: Many NICs compute checksums in hardware

For high-throughput UDP applications (10+ Gbps), hardware checksum offload is essential. Setting the checksum field to 0 (disabling checksum) was once a performance optimization but is now unnecessary with hardware offload.

We've explored the connectionless paradigm embodied by UDP—a radically simple alternative to connection-oriented services. This knowledge prepares us to compare the two paradigms and understand when each is appropriate.

Looking ahead:

We now understand both paradigms: connection-oriented with its guarantees and overhead, connectionless with its simplicity and limitations. The next page explores the trade-offs between them—helping you understand when connection establishment is worth the cost and when connectionless communication is the superior choice.