Redis Client Protocol parsing

In the official website Http://redis.io/topics/protocol has the Redis communication protocol to make the explanation.
For some of the reasons below, I would like to parse Redis client protocol:

1, enough understanding of communication protocols, help to make better system design.

2, Learning resp design ideas, not only can expand my thinking, perhaps in the future can be applied to my code.

3. Because some people want to integrate the Redis client directly into their existing systems, including me. This will be explained in my next article.

Below I translate http://redis.io/topics/protocol some of what I think is important:

Redis clients communicate with the Redis server using a protocol called RESP (Redis serialization protocol). While the protocol is designed specifically for Redis, it can is used for other client-server software projects.

RESP is a compromise between the following things:

• Simple to implement.
• Fast to parse.
• Human readable.

RESP can serialize different data types like integers, strings, arrays. There is also a specific type for errors. Requests is sent from the client to the Redis server as arrays of strings representing the arguments of the "command to Ex" Ecute. Redis replies with a command-specific data type.

RESP is Binary-safe and does not require processing of bulk data transferred from one process to another, because it uses Prefixed-length to transfer bulk data.

Note:the protocol outlined here are only used for client-server communication. Redis Cluster uses a different binary protocol in order to exchange messages between.

Translated:

The Redis client and Redis server use a protocol called RESP (Redis serialization Protocol) to communicate. Although this protocol is specifically designed for Redis, it can be used in other software projects based on the C/S model.

Resp is a compromise based on some of the following facts:

• Easy to implement
• Quick explanation
• Human readable

RESP can serialize different data types, such as integers, strings, arrays, and special error types. The client sends an array of strings to the service side, while the string array represents the command parameters to execute. Redis will reply with a specific command type.

RESP is binary safe, and there is no need for a lot of data processing in process conversions because it uses prefix lengths to convert bulk data.

Note: The protocols outlined here are only for client-server communication. The Redis cluster uses a different binary protocol for exchanging messages for different nodes.

RESP is actually a serialization protocol that supports the following data types:simple Strings, Errors, integers, Bulk S Trings and Arrays.

The RESP is used in Redis as a request-response protocol is the following:

• Clients send commands to a Redis server as a RESP Array of Bulk Strings.
• The server replies with one of the RESP types according to the command implementation.

In RESP, the type of some data depends on the first byte:

• For simple Strings the first byte of the reply is "+"
• For Errors The first byte of the reply is "-"
• For integers the first byte of the reply is ":"
• For Bulk Strings The first byte of the reply is "$"
• For Arrays The first byte of the reply is " * "

Additionally RESP is able to represent a Null value using a special variation of Bulk Strings or Array as specified later.

In RESP different parts of the protocol is always terminated with "\ r \ n" (CRLF).

Translated:

Resp is actually a serialization protocol that supports the following data types: short strings, errors, integers, long strings, and arrays.

As a request-response protocol, RESP is used in Redis in the following ways:

• The client sends a command like a long string array in resp to the Redis server.
• The Redis server responds to one of the RESP types according to the command.

In RESP, a data type is based on the first byte:

• For a short string, the first byte of the reply is "+"
• For errors, the first byte of a reply is "-"
• For integers, the first byte of a reply is ":"
• For long strings, the first byte of a reply is "$"
• For arrays, the first byte of a reply is "*"

In addition, RESP can use a specified long string or an array of special variables to represent null values.
In Resp, the different parts of the agreement are always ended with "\ r \ n" (CRLF).

As mentioned earlier, I have emphasized that the client, which is the protocol used by the server to reply to the client request, only needs to add "\ r \ n" to the command after the client requests the server.

Here are 5 types of return instances:

Assume that the following key-value pairs exist in Redis server: name1catage110 short string "Set name2 fish\r\n" "+ok\r\n" error "Seet name3 dog" "-err unknown Command ' seet ' \ r\n "integer" Incr age1 "": 11 "long string ①" Get name1\r\n "" $3\r\ncat\r\n "②" Get name3\r\n "" $-1\r\n "Array ①" Mget name1 age1\r\n "" *2\r\n$3 \r\ncat\r\n$2\r\n11\r\n "②" Mget name2 age2\r\n "" *2\r\n$4\r\nfish\r\n$-1\r\n "③ other cases will return" *-1\r\n "and" *0\r\n ", Refer to the official Redis documentation for details;

Redis Client Protocol parsing