skip to content

How does a UDP socket differ from a TCP socket in the socket API, and what does calling connect() on a UDP socket actually do?

level: middleimportance: nice to knowfreq 22%

answer

  1. no listen, no accept
  2. one socket, many peers
  3. one call, one datagram
  4. connect here is purely local
  5. errors arrive later, if at all

basics

~20 s

A UDP socket never listens or accepts: one bound socket trades datagrams with any peer, sendto naming the destination and recvfrom returning one whole datagram and its sender. connect() on UDP sends nothing; it sets a default peer and filters locally.

solid answer

~50 s

A UDP socket has no `listen` or `accept`: after `bind`, one socket exchanges **datagrams** with any number of peers. `sendto` names the destination on every call and each call becomes one datagram; `recvfrom` returns exactly one datagram plus the sender's address, so message boundaries are preserved, unlike TCP's byte stream, and on common stacks a buffer that is too small loses the rest of that datagram. Calling `connect` on a UDP socket sends **nothing** — RFC 8085 calls it only a local operation: it records a default peer so plain `send` and `recv` work, filters incoming datagrams to that peer, and on some stacks lets ICMP errors such as Port Unreachable be reported on a later call. The remote side is never told, and UDP has no TIME-WAIT, so a quickly reused port can receive a previous application's delayed datagrams.

go deeper

for a junior

Recall that UDP has no listen or accept, that each sendto is one datagram, and that recvfrom tells you who sent it.

for a middle

Explain connect() on UDP precisely: no packet, a default peer, source filtering, and error reporting — and why message boundaries survive where TCP's do not.

for a senior

Use the model in production reasoning: silent failures on unconnected sockets, unchecked source addresses, reply-address mismatches on multihomed hosts, and stray datagrams after a fast port reuse.

for a principal

Judge when UDP's missing state is a feature and when it is a liability: every guarantee TCP's socket gave for free becomes a design obligation of the application.

## Same API, different model The socket API serves both transports, but the calls mean different things. RFC 8085 (Section 5) spells out the differences because, as it says, programmers are usually more familiar with the TCP side. | Step | TCP socket | UDP socket | |---|---|---| | Create | `socket()` | `socket()` | | Name the local end | `bind()` | `bind()` | | Wait for peers | `listen()`, then `accept()` per connection | none — the bound socket already receives | | Send | `send()` on a connected handle | `sendto(data, peer)`, or `send()` after `connect()` | | Receive | `recv()` returns bytes of a stream | `recvfrom()` returns one datagram and its sender | | `connect()` | runs the three-way handshake | local only; nothing is sent | | End | `close()` starts a FIN exchange | `close()` sends nothing | The key difference is **state**. A TCP server gets one handle per connection; a UDP server normally serves every client through **one** socket, because the protocol has no connections to hand out. ## Sending and receiving datagrams - **One call, one datagram.** Each `sendto` produces exactly one UDP datagram. The receiver never sees two sends merged or one send split across two reads, as it can with TCP's byte stream. - **`recvfrom` returns the sender.** The address comes back with every datagram, which is how a single socket replies to many clients. - **Buffer size matters.** A receive buffer smaller than the datagram does not leave the remainder for the next call; on common stacks the excess is discarded. - **Zero-length datagrams are valid.** RFC 8085 notes that a UDP receiver can get an empty datagram, which "is different from a return value of zero from a read() socket call, which for TCP indicates the end of the connection". - **Anyone can send to you.** RFC 8085 says applications that need datagrams from a particular source "MUST implement corresponding checks at the application layer or explicitly request that the operating system filter the received packets". ## What connect() does on a UDP socket RFC 8085 describes a connected UDP socket as one bound "to a specific pair of addresses and ports", and stresses that "for UDP, this is only a local operation that serves to simplify the local send/receive functions and to filter the traffic". Concretely: 1. **No packet is sent.** "UDP does not notify the remote end when a local UDP socket is bound." 2. **A default peer is recorded**, so plain `send` and `recv` work without an address on every call. 3. **Incoming datagrams are filtered**: only those from the connected address and port are delivered to this socket. 4. **Errors get an owner.** RFC 1122 (Section 4.1.3.1) says a host receiving a datagram for a port with no listener SHOULD send ICMP Port Unreachable, and (Section 4.1.3.3) UDP MUST pass ICMP errors up to the application. They arrive asynchronously, though, and RFC 8085 notes that "on some stacks" it is the bound, connected socket that lets the application be notified. A connected socket typically sees such an error on a later `send` or `recv` as connection refused. Calling `connect` does not make UDP reliable, ordered or flow-controlled; the datagram delivery model is unchanged. ## Server patterns and multihoming - A UDP server usually binds one socket and loops on `recvfrom`, answering each datagram with `sendto` to the address it came from. - On a host with several addresses, RFC 8085 says a reply SHOULD use the source address the request was sent to, because middleboxes often drop replies from a different address. ## What a UDP socket does not have - **No TIME-WAIT.** RFC 8085 points out that TCP keeps TIME-WAIT to stop delayed packets from a closed connection being taken for a later one, and "the UDP protocol does not implement such a mechanism". An application that binds a port just after another exits may receive the old application's delayed datagrams. - **No flow control.** If the application reads too slowly, the receive buffer overflows and datagrams are lost. - **No close notification.** Closing a UDP socket sends nothing, so a peer learns of it only through the application's own messages, silence, or an ICMP error to a later datagram.

  • Why might a UDP client that never called connect() never learn that the server's port is closed?
    The server host SHOULD answer with ICMP Port Unreachable (RFC 1122), and UDP MUST pass ICMP errors up, but they arrive asynchronously and an unconnected socket has no single peer to attribute them to, so on many stacks only a connected socket reports them. A connected socket gives the error an owner: a later send or receive fails with a connection-refused error.
  • Can one UDP socket serve many clients, and what must the server check?
    Yes — one bound socket receives from any source, and that is the normal design. Because anything can arrive, RFC 8085 requires applications that care about the source to check the address themselves or ask the stack to filter. On a multihomed host a reply SHOULD leave from the address the request was sent to.

saying these in an interview costs you the question

  • connect() on a UDP socket performs a handshake with the peer.
  • A UDP server needs listen() and accept() just like a TCP server.
  • recvfrom can return half a datagram now and the rest on the next call.
  • Two sendto calls can arrive merged into one recvfrom result.
  • A UDP recv that returns zero bytes means the peer closed its socket.