UDP Socket Programming Basics

Why UDP Socket Programming Looks Different

Since UDP (covered earlier in this project) has no connection setup at all, its socket programming pattern skips several steps that TCP requires - there's no handshake, and often no persistent "connected" state to maintain between messages.

On the Server Side

1. socket()     - create a new socket
2. bind()       - attach it to a specific IP address and port
3. recvfrom()   - wait for an incoming datagram (also tells you who sent it)
4. sendto()     - send a reply back to that same sender

On the Client Side

1. socket()   - create a new socket
2. sendto()   - send a datagram directly to the server's address (no connect needed)
3. recvfrom() - wait for a reply

Why There's No connect() Step Required

Because UDP has no notion of an established connection, there's no handshake to trigger and no persistent connection state to set up in advance - a UDP client can simply address and send a datagram directly, without any prior setup step.

Why recvfrom() Replaces recv()

Since a UDP server has no fixed, connected client the way a TCP server does, recvfrom() also returns the sender's address alongside the data itself - necessary information, since without an established connection, the server otherwise has no built-in way of knowing who to send a reply back to.

The Practical Trade-off Programmers Must Handle Themselves

Because UDP provides no delivery guarantee, an application using UDP sockets that actually needs reliability - detecting lost datagrams, retrying, or reordering - must implement that logic itself in code, rather than getting it automatically from the transport layer the way TCP provides it.