Basic Networking and Connectivity

A player says the internet is down. How do they know? Their game won't connect. That's evidence the game won't connect — it isn't yet evidence the entire internet is down. There could be a problem with the game, the account, the computer, the cable, the network adapter, the switch, the router, the internet connection, DNS, or the game service itself. Sorting through which one it actually is is what this week teaches.

The network is a path

When you join an online match, your computer doesn't magically reach another computer. Information travels a path: player PC, network interface, Ethernet or Wi-Fi, switch, router, internet, game service — and back again.

What each piece actually does

A network interface lets the computer connect to a network at all. A switch connects devices inside a local network — an esports lab full of PCs typically connects through one or more switches. A router connects different networks and moves traffic between them. A server is a computer or service that other systems use — a game service, a website, an authentication service, a voice service — and most servers aren't physically sitting in the classroom.

Addressing, DHCP, and DNS

Delivering information anywhere requires knowing where it's going, which is what an IP address is for — no subnetting expertise required this week, just the idea that communication needs a destination. DHCP automatically provides a device with the network configuration it needs when it joins. DNS translates names people can remember into the addressing information systems actually use.

One match, many dependencies

Game, account/login, network configuration, local network, router, internet connection, remote game service — if any important link in that chain fails, the player experiences the same symptom: "game won't connect." Same symptom, different possible causes.

Lesson 1: How Devices Connect

Build the basic network — interface, switch, router, addressing, DHCP, DNS, services — by tracing traffic rather than memorizing definitions.

Lesson 2: Diagnosing a Connectivity Scenario

Stop asking "is the internet broken" and start gathering evidence. Learn to read failure patterns: one computer, several computers, all computers, one application, everything.

Lesson 3: Network Troubleshooting Simulation

Diagnose a fictional lab network under time pressure with a limited number of tests, then document a Network Troubleshooting Case Report.

Week 16 artifact

Your final artifact is a Network Troubleshooting Case Report, documenting: symptom, system path, possible causes, test, evidence, narrowed possibilities, and likely cause.

Learning targets

By the end of Week 16, you should be able to:

• distinguish a local network from a remote service
• explain the basic roles of switches and routers
• explain why devices need network addresses
• describe the basic purposes of DHCP and DNS
• trace a simplified connection from an esports PC to an online service
• identify shared network dependencies
• use failure patterns to narrow possible causes
• distinguish a symptom from a root cause
• select useful diagnostic tests instead of guessing
• document a network troubleshooting process using evidence

One idea to keep: when someone says "the internet is broken," don't argue — ask what still works. That question alone can eliminate half the possibilities.