Client and Server are Just Roles
So what did you come up with from yesterday's challenge?
I gave you a hint that the terms "client" and "server" are somewhat fluid labels. These terms describe roles in a transaction more than they describe anything intrinsic to a machine or process.
Here's an example of what I mean. The way to create our terminal clients in a browser while still maintaining access to the GPIO pins is to write two separate processes to run on the same machine. One process, which we'll call the local server, will be run from the OS with access to events on the GPIO pins. This server can also serve a static web app for the UI. The browser app communicates with the local server via HTTP, web sockets, or any other appropriate protocol to coordinate user interactions between screen and GPIO.
So which of these processes communicates with the central game server? You could probably do it either way. For argument's sake, let's say that we configure the local server (the GPIO app) to communicate with the game server and forward necessary messages between the game server and the browser UI. In this instance, the local server is acting as a client to the game server. This is what I mean when I say that client and server are roles in a transaction. When a user provides input to the browser which sends a message to the local server to light an LED on GPIO 12, the browser is acting as client and the local server is acting as server. But the local server may turn around and act as client by sending a message to the game server that a certain task has been completed at the terminal.
The roles get even muddier when you consider bidirectional communication protocols like web sockets. When we're just talking about HTTP, you can easily say that the client is the process that initiates the request, and the server issues a response. In the case of duplex communication, the client is generally the process that requested the connection.
Making sense? More tomorrow.