Skip to content
Atlas, your robot learning host

Interim portrait

Atlas · Foundations client-server

Hello, little human. I am Atlas. One useful idea is plenty for a beginning. Read the explanation, then explore an example.

Choose your robot No recording yet · text complete
concept for everyone
  • web

Client and Server

In a client/server interaction, the client initiates a request and the server responds; these are roles in that interaction, not permanent kinds of device.

Tune in, human.

Reviewed videos and Shorts

Captions requested · no autoplay

Finding reviewed videos…

    Keep the useful bits, human.

    Beginner field notes

    Choose explanation level
    • In an HTTP exchange, the client asks for something and the server sends a response. Start by finding who sent the request.
    • Client and server describe programs. Your browser is a client when it asks a website for a page.
    • When the server answers, it is still the server for that exchange; the reply does not swap the roles.
    See a worked example

    Name the role separately for each interaction

    Sample only. Nothing here runs on your computer.

    Example input · do not paste
    Offline Lantern Archive trace:
1. Browser asks Archive service for B7's current label.
2. Archive service asks Label store for B7's saved label.
3. Label store replies to Archive service: Seeds.
4. Archive service replies to Browser: Seeds.
Assume every listed message arrives, each reply belongs to the stated request, both reads complete, and no label is changed.
    Example output · do not paste
    Browser ↔ Archive interaction: Browser is the client; Archive service is the server.
Archive ↔ Label store interaction: Archive service is the client; Label store is the server.
Both replies carry Seeds. The same Archive program has two different roles across the two interactions. No label change is requested or performed.

    Find the initiator of each request and the program answering it. Classify each pair separately; the direction of a reply does not swap that pair's roles. This is a written trace, not a connected browser, server or database.

    Visual

    The browser requests B7's label from Archive. Archive then requests it from the label store. Seeds returns through Archive to the browser. Archive is a server for the first interaction and a client for the second.

    The reviewed description and complete diagram source are available here.

    Read the complete diagram source

    This is the source for the reviewed diagram, not a command to run.

    sequenceDiagram
  participant B as Browser
  participant A as Archive service
  participant S as Label store
  B->>A: Ask for B7 label
  A->>S: Ask for stored B7 label
  S-->>A: Seeds
  A-->>B: Seeds
    Sources and full explanation

    Notes sources · Beginner

    AI source review · 2026-10-17

    Reviewed explanation

    A client is the program that starts a request in an interaction. A server is the program that handles that request and sends a response. For example, your browser can ask a website for a page, and the website's server can answer with the page. You do not need a terminal or programming language to follow who asked and who answered.

    Client and server name roles, not a person's importance or permanent categories of computer. A server is often a program running on a computer, and several programs can share one computer. A browser is a familiar client, but another service can also be a client. These names tell us about an interaction, not how powerful a device is.

    In our fictional Lantern Archive, the browser asks the Archive service for box B7's label. Archive asks a separate label store for the saved label, then answers the browser. Archive is the server for the browser's request and the client for its own request to the store. Returning an answer does not make the original server become the client of that same interaction.

    This request/response pattern is the part we are studying. The worked example explicitly says that every message arrives and the two reads finish. In a real system a request or response might be delayed or lost. Seeing a request sent does not, by itself, tell you that an answer arrived or that all work finished. HTTP is one protocol that uses these roles; this lesson does not claim that every kind of communication is a simple request followed by one answer.

    • MDN: How the web works — Clients and servers

      Provides the browser/web-server request and response introduction. Used for this familiar example, not to claim that clients must be browsers or that each role needs its own physical computer.

    • RFC 9110: HTTP Semantics, sections 3.3–3.4

      Defines HTTP clients and servers as programs with roles for a connection; the same program can have different roles on different connections. This supports the interaction-role distinction, not a universal protocol model or completion guarantee.

    AI source comparison recorded 2026-10-17. Human learner validation is pending.

    Quick quiz · one question

    Who initiates each interaction?

    Sample scenario. Synthetic Lantern Archive interactions. Each listed pair explicitly states who initiates and responds; no packets, arrival order or permanent machine roles are inferred.

    viewer-to-archive
    Archive viewer initiates; Archive service responds. These roles apply to this interaction.
    archive-to-catalog
    Archive service initiates; Label catalog responds. These roles apply to this interaction.

    Read the two labeled request/reply pairs. Which program is client and which is server in each pair?

    Answers stay on this device.

    Sources and exercise scope
    • MDN: How the web works — Clients and servers

      Provides the browser/web-server request and response introduction. Used for this familiar example, not to claim that clients must be browsers or that each role needs its own physical computer.

    • RFC 9110: HTTP Semantics, sections 3.3–3.4

      Defines HTTP clients and servers as programs with roles for a connection; the same program can have different roles on different connections. This supports the interaction-role distinction, not a universal protocol model or completion guarantee.

    Original synthetic exercise. AI comparison against the reviewed lesson recorded on 2026-10-17; the references above state their scope. Human learner validation has not been run. A result here records this attempt; it does not establish mastery.

    Save or adjust this lesson
    Reference notes · file removal and public access

    Robot reference desk

    Understand what can change

    These reviewed public notes are available to everyone. They do not establish that an operation ran or inspect your files, backups or permissions.

    File removal

    Before deleting files: deleting a file can remove it without putting it in Trash or a recycle bin, and recovery is not guaranteed. Check the intended targets and whether a usable backup or recovery option exists before continuing.

    Sources for this note

    Public access

    Before making a resource public: public read access can let anyone view the exposed content, and public write access can allow changes to data. Check the actual audience, exposed content and allowed operations before continuing. This guidance does not inspect or change your permissions.

    Sources for this note

    A link can carry these public reference topics in its fragment. Page scripts, extensions, browser history and copied links can read them. This page attempts to minimize that fragment when JavaScript runs; reloading afterward can lose the selection. No project details or conversation text belong in a lesson link. Privacy details.