<b>ProtocolSpecification: Contents</b><br> <ahref="#Protocol Specification">Protocol Specification</a><br> <ahref="#Networking layer">Networking layer</a><br> <ahref="#Simple INLINE commands">Simple INLINE commands</a><br> <ahref="#Bulk commands">Bulk commands</a><br> <ahref="#Bulk replies">Bulk replies</a><br> <ahref="#Multi-Bulk replies">Multi-Bulk replies</a><br> <ahref="#Nil elements in Multi-Bulk replies">Nil elements in Multi-Bulk replies</a><br> <ahref="#Single line reply">Single line reply</a><br> <ahref="#Integer reply">Integer reply</a><br> <ahref="#Multiple commands and pipelining">Multiple commands and pipelining</a>
to get a first feeling of the protocol playing with it by TELNET.<h2><aname="Networking layer">Networking layer</a></h2>A client connects to a Redis server creating a TCP connection to the port 6379.
Every redis command or data transmitted by the client and the server is
terminated by "\r\n" (CRLF).<h2><aname="Simple INLINE commands">Simple INLINE commands</a></h2>The simplest commands are the inline commands. This is an example of a
server/client chat (the server chat starts with S:, the client chat with C:)<br/><br/><preclass="codeblock python"name="code">
</pre>An inline command is a CRLF-terminated string sent to the client. The server can reply to commands in different ways:
<ul><li> With an error message (the first byte of the reply will be "-")</li><li> With a single line reply (the first byte of the reply will be "+)</li><li> With bulk data (the first byte of the reply will be "$")</li><li> With multi-bulk data, a list of values (the first byte of the reply will be "<codename="code"class="python">*</code>")</li><li> With an integer number (the first byte of the reply will be ":")</li></ul>
The following is another example of an INLINE command returning an integer:<br/><br/><preclass="codeblock python python"name="code">
NULL, and so forth.<h2><aname="Multi-Bulk replies">Multi-Bulk replies</a></h2>Commands similar to LRANGE needs to return multiple values (every element
The first byte of a multi bulk reply is always <codename="code"class="python">*</code>. Example:<br/><br/><preclass="codeblock python python python python python python"name="code">
happens. This makes possible to distinguish between empty list and non existing ones.<h2><aname="Nil elements in Multi-Bulk replies">Nil elements in Multi-Bulk replies</a></h2>Single elements of a multi bulk reply may have -1 length, in order to signal that this elements are missing and not empty strings. This can happen with the SORT command when used with the GET <i>pattern</i> option when the specified key is missing. Example of a multi bulk reply containing an empty element:<br/><br/><preclass="codeblock python python python python python python python python"name="code">
</pre>The second element is nul. The client library should return something like this:<br/><br/><preclass="codeblock python python python python python python python python python"name="code">
</pre>The client library should return everything after the "+", that is, the string "OK" in the example.<br/><br/>The following commands reply with a status code reply:
PING, SET, SELECT, SAVE, BGSAVE, SHUTDOWN, RENAME, LPUSH, RPUSH, LSET, LTRIM<h2><aname="Integer reply">Integer reply</a></h2>This type of reply is just a CRLF terminated string representing an integer, prefixed by a ":" byte. For example ":0\r\n", or ":1000\r\n" are integer replies.<br/><br/>With commands like INCR or LASTSAVE using the integer reply to actually return a value there is no special meaning for the returned integer. It is just an incremental number for INCR, a UNIX time for LASTSAVE and so on.<br/><br/>Some commands like EXISTS will return 1 for true and 0 for false.<br/><br/>Other commands like SADD, SREM and SETNX will return 1 if the operation was actually done, 0 otherwise.<br/><br/>The following commands will reply with an integer reply: SETNX, DEL, EXISTS, INCR, INCRBY, DECR, DECRBY, DBSIZE, LASTSAVE, RENAMENX, MOVE, LLEN, SADD, SREM, SISMEMBER, SCARD<h2><aname="Multiple commands and pipelining">Multiple commands and pipelining</a></h2>A client can use the same connection in order to issue multiple commands.
Pipelining is supported so multiple commands can be sent with a single
write operation by the client, it is not needed to read the server reply
in order to issue the next command. All the replies can be read at the end.<br/><br/>Usually Redis server and client will have a very fast link so this is not
very important to support this feature in a client implementation, still
if an application needs to issue a very large number of commands in short
