Redis clients talk to the server using the REdis Serialization Protocol (RESP). Describe how a command and its reply are framed on the wire, and name the basic RESP2 data types with their prefix bytes.

## What RESP is RESP (REdis Serialization Protocol) is the wire format between clients and the Redis server. It runs over TCP (port 6379 by default, optionally with TLS wrapping it). Its design goals are stated plainly in the protocol documentation: simple to implement, fast to parse, and human readable. It is not a general-purpose serialization format like Protobuf; it exists only to carry command arguments one way and typed replies the other. ## Request framing: everything is an array of bulk strings A client does not send the text `SET name value`. It sends a **RESP array whose elements are bulk strings**: ``` *3\r\n$3\r\nSET\r\n$4\r\nname\r\n$5\r\nvalue\r\n ``` Read it as: an array of 3 elements; a 3-byte string `SET`; a 4-byte string `name`; a 5-byte string `value`. `\r\n` (CRLF) terminates every line. Two consequences fall out of this: 1. **There is no command syntax to parse.** The server receives an argument vector and dispatches on argument 0. This is why adding a command or a new option requires no grammar change, and why a client library can implement `SEND(*args)` generically. 2. **Arguments are opaque bytes.** Because bulk strings are length-prefixed, an argument may contain spaces, newlines, or arbitrary binary — a serialized image, a protobuf blob. Nothing needs escaping. ## Reply framing: one byte says what it is RESP2 defines five frame types, distinguished by the first byte: **`+` Simple string.** `+OK\r\n`, `+PONG\r\n`. A single line of text with no CR or LF inside, and no length prefix. Cheap to produce and parse; used for short status replies. **`-` Error.** `-ERR unknown command 'FOO'\r\n`, `-WRONGTYPE Operation against a key holding the wrong kind of value\r\n`. Structurally identical to a simple string but the leading `-` tells the client to raise/return an error rather than a value. By convention the **first word is an uppercase error code** — clients and applications branch on `WRONGTYPE`, `NOSCRIPT`, `MOVED`, `ASK`, `LOADING`, `BUSYGROUP`, `NOAUTH`, `OOM`, `READONLY` — and the rest is a human-readable message. **`:` Integer.** `:1000\r\n`. A 64-bit signed integer. Commands like `INCR`, `LLEN`, `DEL`, `EXISTS` reply with this. Boolean-ish commands (`EXPIRE`, `SETNX`, `SISMEMBER`) use `:0` / `:1` in RESP2, since RESP2 has no boolean type. **`$` Bulk string.** `$5\r\nhello\r\n` — a byte count, CRLF, exactly that many bytes, CRLF. **Binary safe**: the length tells the parser precisely how much to read, so the payload may contain CRLF or any byte. `$0\r\n\r\n` is the empty string. **`$-1\r\n` is the null bulk string**, which is how `GET missing-key` says "no such key" — distinct from the empty string, a distinction clients must preserve (Python `None` vs `b""`, Java `null` vs `""`). **`*` Array.** `*2\r\n$3\r\nfoo\r\n$3\r\nbar\r\n` — an element count followed by that many complete RESP frames of any type, including nested arrays. `*0\r\n` is an empty array; **`*-1\r\n` is a null array**, returned for example by a blocking pop that timed out. `LRANGE`, `HGETALL`, `MGET`, and `EXEC` all return arrays; `EXEC` returns an array whose elements are the individual command replies, and `*-1` when a `WATCH` guard aborted the transaction. ## Nesting and heterogeneity An array's elements need not share a type. `XRANGE` returns arrays containing an id bulk string and a nested array of field/value bulk strings. `CONFIG GET` returns a flat array alternating name and value in RESP2, and `HGETALL` likewise returns a flat `field, value, field, value` array — the client library is what reassembles it into a map. This flattening is one of RESP2's real weaknesses and is exactly what the RESP3 map type fixes. ## Why CRLF and why text Every frame line ends with `\r\n`. Combined with the leading type byte and the explicit length prefixes, this makes the protocol trivially parseable with a state machine and no lookahead beyond the declared lengths — the server never has to scan for a delimiter inside a payload. It is also debuggable: you can read a packet capture, or drive a server from `nc`, without a decoder. ## The client's job A client library is therefore mostly: serialise `args` into `*N` + `$len` frames; write them; read one frame; map the frame type to a language value; special-case the null bulk string; and raise on `-`. Pipelining is nothing more than writing several request arrays before reading, because replies come back in the same order as requests on the same connection. Pub/Sub in RESP2 is the awkward exception: subscription messages arrive as ordinary arrays pushed at the client, which is why a RESP2 connection in subscribe mode may only issue subscription-related commands — and it is exactly the problem the RESP3 push type was introduced to solve.