How Devices Connect

You click Join Match. What actually happens? Something has to travel across a network — let's trace it.

Start at the computer

Your station needs a way to reach the network at all. That's the job of the network interface — Ethernet or Wi-Fi, depending on the machine. A fixed esports lab often leans on Ethernet for a stable physical connection, predictable station placement, and easier wired infrastructure to manage. That doesn't mean Ethernet can't fail — it absolutely can.

Simplified: PC, then network interface, then Ethernet cable, then switch. Each arrow is a dependency.

What the switch does

Picture five PCs all cabled into one switch. The switch connects devices on the local network so the lab doesn't need a separate direct cable between every PC and every other PC — that would get unmanageable fast.

This is the same shared-dependency idea from Week 15. If one PC's cable fails, probably one station is affected. If the switch itself fails, multiple stations may be affected at once. Same concept: blast radius.

Then the router

The local network needs a way to reach other networks. Simplified: esports PCs, then switch, then router, then other networks or the internet. The router moves traffic between networks — it's doing a different job than the switch.

For our level: a switch is mostly concerned with connecting devices within the local network, while a router connects networks and helps traffic move between them. That's enough to start reasoning with.

What "the internet" actually is

Not one giant computer somewhere. The internet is a huge collection of interconnected networks, and your esports lab is one small piece connecting toward a much larger system.

Addressing

To deliver something, you need to know where it's going. Networks use addressing systems, and the one we're introducing this week is the IP address. Very simplified: an IP address helps identify where a device or network interface exists within an IP network. You don't need to become a subnetting expert this week — just understand the purpose: information needs a destination, the same way a letter needs an address, though computers obviously aren't mailing tiny envelopes through cables.

Names versus addresses

You don't type a long numeric address every time you want to reach an online service — you type a name. Something has to translate that name into the information computers actually use. That's DNS. For our level: DNS helps systems find network destinations using names humans can remember.

Getting configured automatically: DHCP

When a computer joins a network, something needs to provide it with network settings — an IP address, information about the local network, a path toward other networks, and DNS information. That could be typed in manually, but most school labs use automatic configuration instead. Many networks handle it through DHCP: Dynamic Host Configuration Protocol. For our purposes: DHCP can automatically provide devices with the IP configuration they need to participate on a network. You don't need the full protocol exchange — just the role it plays.

Here's the useful, slightly strange fact: a device might physically connect but still fail to receive usable network configuration. "Cable connected" does not always mean "network ready" — an important distinction for troubleshooting later.

When DNS breaks in a specific way

Imagine you can reach a service by its raw address, but not by its name. That's a strange but informative symptom — it suggests the network itself might still be working while something specific to name resolution has failed. This is exactly why troubleshooting needs targeted tests instead of a single blanket assumption.

Services aren't one thing either

A final connection may depend on several separate remote services — a login service, a game service, a matchmaking service, a voice service. If one of them fails, the entire internet hasn't necessarily failed with it.

Imagine the game launches fine, login works fine, but matchmaking fails. That's not "the entire computer is broken," and it's not "the entire internet is broken" either — the evidence has already narrowed the system considerably.

Network Path Investigation

Here's the Robotnix Arena Network: PC-01 through PC-05 connect through Switch-A, which connects to a router, which connects to the internet, which reaches the game service.

Trace what's involved when PC-03 joins an online match, writing out every major component.

Scenario A. PC-03 can't connect; PCs 01, 02, 04, and 05 can. Would "Switch-A completely failed" be your first hypothesis? Probably not — several other devices sharing that same switch still work fine, and that's evidence against a total switch failure.

Scenario B. Every PC on Switch-A fails, but a computer on Switch-B works normally. Where would you focus? Somewhere in the shared path unique to the Switch-A branch.

Scenario C. Every school device can browse websites, but nobody can reach the game service. Is the school's entire internet connection likely down? Unlikely, since web access still works. What's the more probable culprit? The remote game service itself.

Scenario D. One computer can open websites by address but can't reach them by name. What service becomes the natural suspect? DNS.

Build a simplified network

Your group gets four PCs, one switch, one router, one internet connection, and one game server. Draw the topology, then add DHCP and DNS as services on your diagram — and make sure your diagram visually distinguishes a device, a network device, and a service, since they're different kinds of things doing different jobs.

The word for this arrangement is topology: at our level, network topology describes how network components are arranged and connected. You don't need to memorize every topology type today — you need to be able to read the system in front of you.

Before you leave

Explain this path: player PC, switch, router, internet, game service. For each node, answer what job it performs. Then pick one node and answer what symptom might appear if it failed.

Source note

This lesson directly supports Middle Township Unit 5 requirements involving routers, switches, servers, topology, addressing, system reliability, and integrated hardware/software systems.

The simplified DHCP/DNS treatment, the Robotnix Arena topology, the service-dependency model, and the Network Builder are original Robotnix Academy instructional components.