Design a tiny text protocol

You have read HTTP and SMTP by hand. Now design a protocol of your own. Extend the local Node.js server with three commands: TIME, ECHO text, and QUIT.

Choose one line ending and buffer input until a complete line arrives:

let buffer = ''

socket.on('data', chunk => {
  buffer += chunk.toString('utf8')
  let index
  while ((index = buffer.indexOf('\r\n')) !== -1) {
    const line = buffer.slice(0, index)
    buffer = buffer.slice(index + 2)
    handleLine(socket, line)
  }
})

The while loop matters. One data event may carry zero, one, or three complete lines. TCP supplies a stream, so one data event is not the same as one command.

Return one numeric reply per command, SMTP-style:

200 2026-08-03T10:00:00Z
200 hello
400 unknown command
221 bye

Numeric codes let a client program check the first three characters without parsing the whole line. Humans read the text after the code. Machines read the code.

Connect with your Telnet client and test the happy path:

TIME
200 2026-08-03T10:00:00Z
ECHO hello
200 hello
QUIT
221 bye
Connection closed by foreign host.

Then test the ugly paths. Send an unknown command and confirm you get 400 unknown command instead of silence. Test fragmented input and two commands arriving in one read. Netcat can do that: printf 'TIME\r\nECHO hi\r\n' | nc 127.0.0.1 2323 delivers two commands in a single write.

Write the contract down

Document the command grammar, reply grammar, encoding, maximum line length, timeout, and close behavior. A protocol without a maximum line length invites a client to send an endless line and eat your memory. A protocol without a timeout collects dead connections forever.

You now have an application protocol that a Telnet client can demonstrate. It is not the Telnet protocol unless you also implement Telnet commands and negotiation. The distinction from earlier lessons applies to your own work too: the tool speaks TCP, your protocol defines what the bytes mean.