TCP and UDP/Sending without promises/Which device, which app
Lesson 2 of 12 · in 3D and VR

Which device, which app

An IP address picks the machine and a 16-bit port picks the program on it. TCP and UDP each keep their own set of port numbers, so the same number on the two is two different doors.

Lonely BinaryUpdated 2026-10-014 min readNo board required

View it in VR

Lesson 2 of the TCP and UDP course opens in a VR headset, on a table in front of you, and a voice starts three seconds after you arrive. Type this short address into the browser on a headset such as Meta Quest or Apple Vision Pro, and press Enter VR. No headset? Press Start the lesson: the same lesson, full screen.

learn.lonelybinary.com/vr/tcp-udp/2

A machine on a network runs many programs at once: a web server, a time client, a sensor feed. A datagram that reaches the machine still has to reach the right one, so every TCP segment and every UDP datagram carries two more numbers in its header, a source port and a destination port. Each is 16 bits wide.

The IP address does the first job and the port does the second. The address gets the datagram to the machine, and the port gets it to the program on it. Port 0 is reserved in practice.

The addresses in the lesson

The lesson uses private IPv4 addresses, 192.168.1.21 and 192.168.1.22, which differ only in the last number. That is how two devices on one home network look. IPv6 addresses are longer, and the course leaves them out.

Two shelves, not one

TCP and UDP have separate port spaces. A program listening on TCP port 5000 does not receive UDP datagrams addressed to port 5000, and the reverse. The two are different books on different shelves. The IANA registry shows it by listing every well-known port twice, once for each protocol: MQTT's 1883 appears as a TCP row and as a UDP row. Many services use only one of the two, and some, such as DNS on port 53, use both.

What the four numbers name

A UDP datagram is delivered by its destination address and port; the sender's address is only information unless the program checks it. A TCP connection is more specific. RFC 9293 defines it by a pair of sockets, which is four numbers: the address and port at one end, and the address and port at the other. That is why one web server on port 80 can talk to many clients at once. Each client's address and source port make a different connection to the same book.

What it costs when it goes wrong

The right address with the wrong port reaches the machine and stops there. Nobody is listening for that port on that protocol, so nothing reads the datagram. For UDP the sender usually hears nothing, unless the network returns an error message, which a program often never sees. The program simply gets no answer. For TCP the attempt to connect is normally refused, which is quicker to diagnose than silence.

The wrong address sends the datagram to a different machine entirely. If that machine has a program on the same port, it receives data meant for another. This is why the address and the port are only meaningful as a pair.

Common mistakes

  • Opening a TCP port and sending UDP to it. A listener on TCP 5000 does not hear UDP 5000. Check the protocol as well as the number.
  • Assuming the port number says what the program is. Port 80 is the convention for HTTP, not a rule the network enforces.
  • Forgetting the sender's port. It is chosen by the sender's machine, and it is half of what lets a reply find its way back.

Edit this page — content/fundamentals/tcp-udp/address-and-port.mdx

Discuss this article

Ask about this page. The answer stays here, on the page it belongs to, for whoever hits the same wall next.

Browse Fundamentals on the forum →