Skip to content

Latest commit

 

History

History
68 lines (48 loc) · 3.27 KB

RedisProtocolNotes.md

File metadata and controls

68 lines (48 loc) · 3.27 KB
Raw

RESP (Redis Serialization Protocol)

Short quotes from http://redis.io/topics/protocol. The reader is strongly encouraged to read the original document. This is a cheat sheet for development reference.

Another reference that details the C language implementation of Redis Strings, entitled Hacking Strings can be found at http://redis.io/topics/internals-sds

For Redis Events and their C implementation, see http://redis.io/topics/internals-rediseventlib

  • Requests are sent from the client to the Redis server as arrays of strings representing the arguments of the command to execute.
  • Redis replies with a command-specific data type
  • binary-safe
  • uses prefixed-length to transfer bulk data
  • a serialization protocol that supports the following data types: Simple Strings, Errors, Integers, Bulk Strings and Arrays

RESP Response Types

  • send commands to a Redis server as a RESP Array of Bulk Strings
  • server replies with one of the RESP types:
    1. Simple Strings the first byte of the reply is "+"
    2. Errors the first byte of the reply is "-"
    3. Integers the first byte of the reply is ":"
    4. Bulk Strings the first byte of the reply is "$"
    5. Arrays the first byte of the reply is "*"
    6. RESP is able to represent a Null value using a special variation of Bulk Strings or Array
  • different parts of the protocol are always terminated with "\r\n" (CRLF)

Simple Strings

  • +OK\r\n
  • non binary safe strings
  • for binary safe use Bulk Strings
  • a client library should return to the caller a string composed of the first character after the '+' up to the end of the string, excluding the final CRLF bytes

Errors

  • -Error message\r\n, identical to Simple Strings
  • An exception should be raised by the library client when an Error Reply is received
  • A client implementation may return different kind of exceptions for different errors, or may provide a generic way to trap errors by directly providing the error name to the caller as a string. However, such a feature should not be considered vital as it is rarely useful, and a limited client implementation may simply return a generic error condition, such as false.

Integers

  • :1000\r\n
  • a CRLF terminated string representing an integer, prefixed by a ":" byte
  • guaranteed to be in the range of a signed 64 bit integer
  • used in order to return true or false

Note: we have "OK" and 1

Bulk Strings

  • $6\r\nfoobar\r\n
  • single binary safe string up to 512 MB in length
  • an empty string is $0\r\n\r\n
  • a Null, or Null Bulk String is $-1\r\n
  • The client library API should not return an empty string, but a nil object, when the server replies with a Null Bulk String. For example a Ruby library should return 'nil' while a C library should return NULL (or set a special flag in the reply object), and so forth

Note: Julia this would be a Union{T, Nothing}, where T is an Integer or AbstractString

Arrays

  • *2\r\n$3\r\nfoo\r\n$3\r\nbar\r\n an Array of 2 Bulk Strings
  • *0\r\n is an empty Array
  • Arrays can contain mixed types
  • Single elements of an Array may be Null: e.g., SORT command when used with the GET pattern option when the specified key is missing

TODO: next section "Sending Commands to Redis"