IP, TCP, and UDP

IP promises almost nothing

IP was designed to survive damage, so it allows many routes between any two points and reroutes around failures. That robustness has a price: the datagrams of one conversation need not follow the same path, so they can arrive out of order, arrive twice, arrive corrupted, or never arrive at all. IP is best-effort delivery — it will try, and it will not tell you it failed.

Java exposes no way to send a raw IP datagram and no way to speak ICMP, IGMP or ARP. The only transport protocols available to you are TCP and UDP, plus whatever application protocols you build on top.

TCP: four guarantees, and what they cost

TCP is layered on top of IP and adds exactly four things:

• A connection. Both ends agree to talk before any data moves, via a three-way handshake (SYN, SYN-ACK, ACK), and both keep state for the life of the conversation.
• Ordering. Every byte is numbered, so the receiver reassembles the original order regardless of arrival order.
• Retransmission. The receiver acknowledges what it got; anything unacknowledged is sent again.
• Flow and congestion control. The receiver advertises how much it can absorb and the sender backs off when the network shows strain.

The bill: one full round trip before the first byte of data can flow, per-connection memory at both ends, and head-of-line blocking — one lost segment stalls everything behind it until the retransmission lands. Harold calls TCP reliable and UDP unreliable; read those as technical labels, not as praise and insult.

TCP is a byte stream, not a message service

This is the most expensive misunderstanding in the course. A TCP connection carries an undifferentiated stream of bytes. One write() of 3,000 bytes may leave as three segments. Three small write() calls may be coalesced into one. A read() returns whatever has arrived so far, which may be one byte or everything.

So TCP will never tell you where your message ends. Framing is your job: terminate lines with CRLF, or send a length prefix, or close the connection to mean "done". Every protocol in this course picks one of those three, and designing that choice deliberately is what module 9 is about.

UDP declines all of it

UDP adds almost nothing to IP: an 8-byte header with ports and a checksum. No connection, no ordering, no retransmission, no flow control. In exchange it is cheap and it keeps message boundaries — one datagram sent is one datagram received, whole or not at all. That is right for voice and video (a late packet is worse than a lost one), for DNS queries (one small question, one small answer, just ask again), and for discovery on a local network.

Worked example — the same 3,000-byte page, over each transport

Take the page from the previous lesson: 3,150 bytes, three segments.

Over TCP. The handshake costs a round trip, then the three segments go out. Suppose the middle one is lost. The receiver acknowledges what it has, the sender retransmits, and the application is handed 3,150 contiguous bytes in the right order. It never learns anything went wrong — it only notices the delay.

Over UDP. No handshake; three datagrams leave immediately. If the middle one is lost, the receiver gets datagram 1 and datagram 3 and has no idea datagram 2 ever existed — unless the application numbered them itself, noticed the gap, and asked again. Do that, and you have started re-implementing TCP, badly. Choose UDP when losing that datagram is genuinely acceptable, not when you plan to fix it yourself.