Writing a Simple TCP Echo Server - Step 0 to Build Your Own Redis | Redis Internals

Main ideas / concepts conveyed

• The video walks through building a very simple TCP echo server in Go (an “echo server” / “Eco server”).
• In this server:
  • Anything a client sends is returned unchanged back to the client.
• The goal is to start from basic TCP socket programming in Go, progressively positioning this as a stepping stone toward understanding Redis internals.
• The server is:
  • Synchronous / single-threaded
  • Able to accept only one TCP connection at a time, because it blocks while reading from the current client.

Project structure and execution flow

Project setup

• Uses Go modules (go.mod) with no external dependencies (everything is written from scratch).

Entry point

• Execution begins in the classic main.go file in the main function.

Command-line flags

• The program sets up two CLI flags:

Port flag

• Default is 7379 (noted as a Redis-like port in the subtitles, with a brief radius/Redis confusion).

Host flag

• Used to choose where to accept connections from.
• Default shown as 0.0.0.0, meaning it listens on all network interfaces (accepting connections from anywhere).

Server startup

• Logs a “starting” message (e.g., “rolling the dice…” / “starting a synchronous TCP server…”).
• Creates a TCP listener using net.Listen:
  • Listens on the specified host and port.

Main accept loop (outer infinite loop)

• Runs an infinite for loop to repeatedly accept new TCP connections.
• Uses a blocking call:
  • listener.Accept()
• After a client connects:
  • Control flow continues after Accept.
  • Increments a client counter (e.g., clients) tracking concurrent clients (though concurrency is limited by design).
  • Logs that a client connected, including the remote address.

Per-client handling loop (inner infinite loop)

• After accepting one connection, the server enters another infinite loop to continuously handle that client.
• Reads messages using a readCommand function which:
  • Takes the TCP connection (socket).
  • Performs a blocking read syscall (described as read).
    • If the client sends nothing, the read blocks and the server can’t progress.
  • Stores received bytes in a buffer.
  • Converts bytes to a string and returns it.

Error / disconnect handling

• If readCommand encounters an error (e.g., client disconnects or socket issue):
  • The server closes the socket.
  • Decrements/adjusts the concurrent clients counter.
  • Logs that the client disconnected and shows the updated client count.
• If the error indicates graceful termination (e.g., EOF):
  • Breaks out of the per-client loop (connection ends).

Echo response

• After successfully reading input:
  • Logs the received command/message.
  • Calls a respond function with the connection and the command.
• For an echo server:
  • respond writes the received command back to the same socket unchanged.

Demonstrated behavior / tests described

Using netcat

• Example: connect with nc to localhost 7379.
• When the client sends text (e.g., hello, world, hello world):
  • The server logs the received message.
  • The client receives the same message back.

Demonstrating single-threaded / single-connection nature

• If a second client tries to connect:
  • “No movement” occurs until the first client disconnects.
• Explanation:
  • The server is stuck in the inner infinite loop reading from the current client, so it can’t return to Accept() to handle a new connection.

Integration concept: what Redis clients send

• The video then connects a Redis client / Redis CLI to this echo server.
• It observes that the Redis client sends data using the Redis Serialization Protocol (RESP) over raw TCP (not HTTP).
• Examples mentioned in the subtitles:
  • On connection, Redis CLI sends sequences like:
    • *1
    • $7
    • ...command...
  • For a SET-like command (example shown as put k v), the server may receive something like:
    • *3
    • new line
    • $3
    • put
    • $1
    • K
    • $1
    • V
• Main takeaway:
  • To build a Redis-compatible server, you must understand and parse RESP framing from the client.

Lessons / takeaway for the “step toward Redis”

• A raw TCP server is only the foundation.
• To speak to Redis clients, you must implement:
  • A serialization protocol parser (RESP),
  • because Redis CLI communicates over raw TCP using a structured format.

Speakers or sources featured

• Primary speaker / narrator: The video creator (no name provided in subtitles).
• Tools/clients referenced as sources:
  • Go (golang) runtime and standard library (e.g., main.go, net.Listen, blocking Accept, blocking socket read).
  • netcat (nc) as a test client.
  • Redis CLI / Redis client as a test client (mentioned as redis-cli, redis-cli radius cli in subtitles).
• Code repository source:
  • Mentions a GitHub repository:
    • github.com / “go to the first commit” (exact path not fully specified in subtitles).