RESP3

HotKV speaks both versions of the Redis serialization protocol. Every connection starts in RESP2, the protocol every Redis client understands. RESP3 adds reply types that say what the data is (a map, a set, a floating-point number, a null) so that client libraries can turn replies into native types without knowing each command’s reply shape, and it adds push messages for out-of-band data such as Pub/Sub messages.

All official HotKV SDKs (Python, Node.js, Go, Java) ask for RESP3 when they connect and fall back to RESP2 automatically. You only need this page if you write a client, read raw replies, or want to understand why a reply looks different in redis-cli -3.

Switching protocols with HELLO

HELLO [protover [AUTH username password] [SETNAME clientname]] switches the connection’s protocol and replies with information about the server. protover is 2 or 3; any other value replies NOPROTO unsupported protocol version. Without arguments, HELLO replies without changing the protocol.

127.0.0.1:6379> HELLO 3
1# "server" => "hotkv"
2# "version" => "8.4.0"
3# "proto" => (integer) 3
4# "id" => (integer) 7
5# "mode" => "standalone"
6# "role" => "master"
7# "modules" => (empty array)

Field	Value
server	Always hotkv
version	The Redis version HotKV is compatible with, 8.4.0. Client libraries use it to decide which commands they can send. INFO server shows HotKV’s own version.
proto	The protocol now in use
id	The connection’s client id, as in CLIENT ID
mode	standalone or cluster
role	master or replica
modules	Always empty: HotKV does not load modules

AUTH authenticates in the same step, which is how a client connects to a server that requires a password without a separate AUTH command. On such a server, HELLO without AUTH from a connection that has not authenticated replies NOAUTH. SETNAME sets the connection name, as CLIENT SETNAME does.

HELLO 2 switches back to RESP2. RESET also returns the connection to RESP2, along with the rest of its initial state.

How replies change

The data is the same in both protocols; only the encoding changes.

Reply	RESP2	RESP3
Missing value (GET of a missing key, BLPOP timeout, …)	Nil bulk string or nil array	Null (_)
Field-value pairs (HGETALL, CONFIG GET, …)	Flat array: field, value, field, value	Map (%)
Unordered members (SMEMBERS, …)	Array	Set (~)
Scores and coordinates (ZSCORE, …)	Bulk string such as "1.5"	Double (,)
Yes/no answers of Bloom filter commands	Integer 1 or 0	Boolean (#t / #f)
Human-readable reports (INFO, …)	Bulk string	Verbatim string (=) with format txt
Pub/Sub messages	Array	Push (>)

127.0.0.1:6379> HSET user:42 name "Ada" lang "en"
(integer) 2
127.0.0.1:6379> HGETALL user:42
1) "name"
2) "Ada"
3) "lang"
4) "en"
127.0.0.1:6379> HELLO 3
...
127.0.0.1:6379> HGETALL user:42
1# "name" => "Ada"
2# "lang" => "en"
127.0.0.1:6379> ZADD board 1.5 ada
(integer) 1
127.0.0.1:6379> ZSCORE board ada
(double) 1.5
127.0.0.1:6379> GET missing
(nil)

Integers, simple strings, bulk strings, errors and plain arrays look the same in both protocols.

Commands whose replies change

Maps. HGETALL, CONFIG GET, HELLO, XREAD and XREADGROUP (a map from stream name to entries), XINFO STREAM, LCS with IDX, MEMORY STATS, LATENCY HISTOGRAM, ACL GETUSER, FUNCTION LIST and FUNCTION STATS, CLIENT TRACKINGINFO, CLUSTER LINKS, CLUSTER SLOT-STATS, BF.INFO, CMS.INFO and TOPK.INFO.

Sets. SMEMBERS, SINTER, SUNION, SDIFF, SPOP with a count, and the flag lists in COMMAND INFO and FUNCTION LIST.

Doubles. ZSCORE, ZMSCORE, ZINCRBY, ZADD with INCR, ZRANK and ZREVRANK with WITHSCORE, the pop commands (ZPOPMIN, ZPOPMAX, BZPOPMIN, BZPOPMAX, ZMPOP, BZMPOP), and coordinates from GEOPOS and WITHCOORD.

Scores with members. Commands with WITHSCORES, such as ZRANGE and ZRANDMEMBER, reply with a flat array (member, score, member, score) in RESP2 and with an array of [member, score] pairs, each score a double, in RESP3:

127.0.0.1:6379> ZRANGE board 0 -1 WITHSCORES
1) 1) "ada"
   2) (double) 1.5

Booleans. BF.ADD, BF.MADD, BF.INSERT, BF.EXISTS and BF.MEXISTS.

Verbatim strings. INFO, CLIENT LIST, CLIENT INFO, and the DOCTOR reports of MEMORY and LATENCY.

Push messages

In RESP3, data the client did not ask for in a reply arrives as a push frame, so a client can tell it apart from command replies on the same connection. HotKV sends push frames for:

• Pub/Sub messages (message, pmessage, smessage) and subscription confirmations (subscribe, unsubscribe, and their pattern and shard versions). See Pub/Sub.
• sunsubscribe notices when a cluster slot moves away and its shard channel subscriptions end.
• Client-side caching invalidations (invalidate, with the keys or a null) and tracking-redir-broken, for a connection that turned on CLIENT TRACKING. See Client-side caching.

Note

A RESP3 connection that is subscribed to channels can run any command, because its messages arrive as pushes that are told apart from replies. A RESP2 connection with subscriptions is limited to subscription commands, PING, QUIT and RESET.

Scripts and RESP3

Inside a Lua script, redis.call() returns replies converted from RESP2 unless the script calls redis.setresp(3). After redis.setresp(3), maps, sets, doubles, booleans and big numbers come into the script as tables such as {map = {...}}, {double = 1.5} or {big_number = "..."}, and a script can return those tables to send the matching RESP3 type to a RESP3 client. A RESP2 client gets the RESP2 form of the same data.

Compatibility

HELLO, the RESP3 reply types and push messages follow Redis 7, and the invalidation pushes of client-side caching follow Redis 8 and Valkey 9.