Memcache protocol Chinese Version

Preface
By accident, I saw the Chinese and English versions of this article, and it seemed not very convenient. So I spent half an hour, carefully sorting out an independent Chinese version, and recording it.

Protocol
The memcached client uses the TCP link to communicate with the server. (The UDP interface is also effective, refer to the "UDP protocol" in the following article) a running memcached server monitors some (configurable) ports. The client connects to these ports, sends commands to the server, reads the response, and closes the connection.

You do not need to send any command to end a session. When the memcached service is no longer needed, the client can close the connection at any time. It should be noted that the client is encouraged to cache these connections, instead of re-opening the connection every time the data needs to be accessed. This is because memcached was designed to enable many connections in a timely manner and work efficiently (hundreds or thousands if needed ). Caching these connections can eliminate the overhead of establishing a connection (/*/the overhead of establishing a new connection on the server is negligible .).

Data sent in the memcache protocol can be divided into text lines and free data. Text lines are used for commands from the client and server responses. Free data is used when the client accesses data from the server. The server returns free data in byte streams. /*/The server does not need to care about the byte sequence of free data. There are no restrictions on the features of free data, but through the text lines mentioned above, the receiver of this data (server or client) can accurately know the length of the database sent.

The text line is fixed with "\ r \ n" (the carriage return followed by a linefeed. Free data will also end with "\ r \ n", but \ r (carriage return), \ n (linefeed), and any other 8-character characters can also appear in the data. Therefore, when the client retrieves data from the server, the length of the data block must be used to determine the end position of the data block, rather than based on "\ r \ n" at the end of the data block ", even if they exist here.

Key Value
Data stored in memcached is identified by key values. A key value is a text string. It must be unique for clients that need to access this data. The current length limit of the key value is set to 250 characters (of course, the client usually does not use such a long key); the key value cannot use tabs and other blank characters (such as spaces, line feed, etc ).

Command
All commands are categorized into three types:
Storage commands (three items: 'set', 'add', and 'repalce ') indicate that the server stores data identified by key values. The client sends a line of command followed by the data block. Then, the client waits for the command line sent by the server to indicate whether the command line is successful or not.
The retrieve command (only one: 'get') indicates that the server returns the data that matches the given key value (one or more key values in one request ). The client sends a line of command, including the key values of all requests. Each time the server finds a content, it will send a line of information about the content back to the client, followed by the corresponding data block; until the server end with a line of "end" response command.
/*? */Other commands cannot carry free data. In these commands, the client sends a line of command, and then waits (determined by the command) for a line of response, or finally ends with a line of "end" multi-line command.

A command line is fixed with the command name, followed by parameters separated by spaces (if any ). The command name is case sensitive and must be in lowercase. Commands sent from some clients to the server contain time limits (actions on content or client requests ). At this time, the specific content of the time limit can be either the Unix timestamp (number of seconds starting from January 1, January 1, 1970) or the number of seconds starting from the current time. For the latter, the value cannot exceed 60*60*24*30 (30 days). If the value is exceeded, the server reads the Unix timestamp instead of the second offset from the current time.

Error string
Every command sent by the client may receive an error string reply from the server. These error strings appear in three forms:
-"Error \ r \ n"
This means that the client has sent a command name that does not exist.
-"Client_error <error> \ r \ n"
This means that some client errors exist in the input command line. For example, the input does not follow the protocol. <Error> some are easy-to-understand error interpretations ......
-"Server_error <error> \ r \ n"
This means that some server errors cause the command to fail to be executed. <Error> some are easy-to-understand error interpretations. In some serious cases (usually not encountered), the server will close the connection after sending this line of error. This is the only situation in which the server closes the connection.
In the description of each subsequent command, these error lines will not be mentioned in particular, but the client must consider the possibility of their existence.

Storage commands
First, the client sends a line like this:
<Command name> <key> <flags> <exptime> <bytes> \ r \ n
-<Command name> is set, add, or repalce.

Set indicates "store this data"
"Add" indicates "store this data only when the server * Does not * retain this key value"
Replace indicates "store this data only when the server * has retained this key value"
-<Key> is the key value of the data to be stored by the client.
-<Flags> stores any 16-bit unsigned integer (written in decimal format) on the server together with the data and sending block When retrieving the content ). The client can use it as a "bit domain" to store specific information; it is not transparent to the server.
-<Exptime> indicates the end time. If it is 0, this item will never expire (although it may be deleted to make room for other cache projects ). If it is not 0 (UNIX timestamp or second offset of the current time point), the client cannot obtain this content after the termination time is reached.
-<Bytes> is the length of the subsequent data blocks, excluding the "\ r \ n" used for field separation ". It can be 0 (followed by an empty data block ).

After this line, the client sends the data block.
<Data block> \ r \ n
-<Data block> is the 8-bit data of a large segment. Its length is specified by <bytes> in the preceding command line.

After sending the command line and data block, the client waits for a reply. The possible replies are as follows:
-"Stored \ r \ n"
Indicates successful.
-"Not_stored \ r \ n"
Indicates that the data is not stored, but it is not because of an error. This usually means that the conditions for the Add or replace command are not true, or the project is already in the delete Queue (refer to the "delete" command in the following article ).

Retrieval command
The command for retrieving a row is as follows:
Get <key> * \ r \ n
-<Key> * indicates one or more key values, strings separated by spaces.
After this command, the client waits for 0 or more projects. Each item will receive a line of text followed by the data block. After all projects are transferred, the server sends the following strings:
"End \ r \ n"
To indicate that the response is complete.
The server sends each item as follows:
Value <key> <flags> <bytes> \ r \ n
<Data block> \ r \ n
-<Key> indicates the key name sent.
-<Flags> indicates the marker set by the storage command.
-<Bytes> is the length of the subsequent data block, * Does not include * its definition character "\ r \ n"
-<Data block> indicates the sent data.

If some key names are sent in the retrieval request and the server does not return the project list, this means that the server does not have these key names (probably because they are never stored, it can also be deleted, expired, or deleted by the client to free up space for other content ).

Delete
The "delete" command allows you to delete content from external sources:
Delete <key> <time> \ r \ n
-<Key> is the key name of the content that the client wants to delete from the server.
-<Time> is a time in seconds (or Unix time that is till a certain moment ), during this time, the server rejects the "add" and "replace" commands for this key name. In this case, the content is put into the delete queue and cannot be obtained through "get", nor can the "add" and "replace" commands be used (but the "set" command is available ). Until the specified time is reached, the content is eventually cleared from the server's memory.
<Time> the parameter is optional. The default value is 0, indicating that the content is cleared immediately and subsequent storage commands can be used ).
This command has a line of response:
-"Deleted \ r \ n"
Indicates that the execution is successful.
-"Not_found \ r \ n"
This content is not found

Refer to the subsequent "flush_all" command to make all content invalid.

Increase/decrease
Commands "incr" and "decr" are used to modify data when some content needs to be replaced, increased, or decreased. The data must be a 32-bit unsigned integer in decimal format. If not, it is treated as 0. The modified content must exist. When you use the "incr"/"decr" command to modify the nonexistent content, it is not treated as 0, but failed.

The client sends the command line:
Incr <key> <value> \ r \ n
Or
Decr <key> <value> \ r \ n
-<Key> is the name of the content that the client wants to modify.
-<Value> indicates the total number of clients to increase/decrease.

The reply is as follows:
-"Not_found \ r \ n"
Indicates the value of the item, which does not exist.
-<Value> \ r \ n, <value> increase/decrease.
Note that the "decr" command overflows: if the client tries to reduce the result by less than 0, the result will be 0 ." The incr command does not overflow.

Status
The "stats" command is used to query the running status and other internal data of the server. There are two formats. Without parameters:
Stats \ r \ n
This will then output the status, set value, and document. Another format has some parameters:
Stats <ARGs> \ r \ n
Through <ARGs>, the server returns various internal data. Because changes may occur at any time, this document does not provide the parameter types and the data returned.

Various statuses
After receiving the "stats" command without parameters, the server sends multiple lines of content as follows:
Stat <Name> <value> \ r \ n
The server uses the following line to terminate the Configuration:
End \ r \ n
In each row, <Name> is the name of the status and <value> indicates the status data. The following lists all status names, data types, and meanings of Data representatives.
In the "type" column, "32u" indicates 32-bit unsigned integer, "64u" indicates 64-bit unsigned integer, "32u: 32u represents two 32-bit unsigned integers separated by colons.

name type description
PID 32u server process id
uptime 32u server running time, unit: seconds
time 32u server current UNIX time
Version String server version
rusage_user 32u: 32u cumulative user time of the Process
(seconds: subtle)
rusage_system 32u: 32u the accumulated system time of the Process
(seconds: subtle)
Number of contents currently stored on the curr_items 32u server
total number of bytes stored since the total_items 32u server was started
bytes 64u the number of bytes occupied by the current storage content on the server
curr_connections 32u connection count
total number of connections received since the total_connections 32u server was running
Number of connection structures allocated by the connection_structures 32u server
cmd_get 32u retrieval request count
cmd_set 32u storage requests
total number of successful get_hits 32u requests
total number of failed get_misses 32u requests
bytes_read 64u total number of bytes the server reads from the Network
total bytes sent by the bytes_written 64u server to the Network
total number of bytes allowed by the limit_maxbytes 32u server during storage

Other commands
The "flush_all" command has an optional numeric parameter. It always runs successfully, and the server sends an "OK \ r \ n" response. The effect is to immediately invalidate an existing project (default) or after the specified time. After the retrieval command is executed, NO content will be returned (unless the same key name is re-stored ). Flush_all does not immediately release the memory occupied by the project, but is executed when new projects are stored in succession. The effect of flush_all is as follows: it causes all items whose Update Time is earlier than the time set by flush_all, and the command is ignored when the retrieval command is executed.
The "version" command has no parameters:
Version \ r \ n
In the response, the server sends the following message:
"Version <version> \ r \ n"
<Version> is the version string of the server.
The "quit" command has no parameters:
Quit \ r \ n
After receiving this command, the server closes the connection. However, you can simply close the connection when the client does not need to send this command.

UDP protocol
When the number of connections from the client is greater than the upper limit of the TCP connection, you can use the UDP-based interface. The UDP interface cannot ensure that the transmission is in place, so it is only used in operations that do not require successful use. For example, when it is used for a "get" request, errors or responses may be lost due to improper cache processing.

Each UDP packet contains a simple frame header. The content after the data is similar to the description of the TCP protocol. In the data stream generated by execution, the request must be contained in a single UDP packet, but the response may span multiple packets. (Except for "get" and "set" requests, multiple data packets are crossed)

The frame header is 8 bytes long and consists of 16 integers in the following format. It is in the byte order of the network and is in the first place ):

0-1 Request ID
2-3 No.
4-5 total number of packets for this information
6-7 reserved bits, must be 0
The request ID is provided by a client. Generally, it is an incremental value starting from the random base, but the client can use any request ID. The server response will contain the same ID as the request. The client uses the Request ID to differentiate each response. Any data packet without a request ID may be delayed due to the delay of the previous request and should be discarded. The number is returned from 0 to n-1, and N is the number of data packets for this information.

End
The earliest source of the original article may be at http://www.alee2002.com/1. now, I can see it in the blogstore in the east of Che. If you are more interested in memcache, refer to the followingArticle:
Install memcache in Linux: http://www.ccvita.com/257.html
Windows memcache installation: http://www.ccvita.com/258.html
Memcache basic Tutorial: http://www.ccvita.com/259.html
Discuz! Memcache cache implementation: http://www.ccvita.com/261.html
Memcache protocol (http://www.ccvita.com/306.html)
Memcache distributed deployment scheme: http://www.ccvita.com/395.html

 

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/ddxkjddx/archive/2011/01/06/6119492.aspx