+++ /dev/null
-Protocol
---------
-
-Clients of memcached communicate with server through TCP connections.
-(A UDP interface is also available; details are below under "UDP
-protocol.") A given running memcached server listens on some
-(configurable) port; clients connect to that port, send commands to
-the server, read responses, and eventually close the connection.
-
-There is no need to send any command to end the session. A client may
-just close the connection at any moment it no longer needs it. Note,
-however, that clients are encouraged to cache their connections rather
-than reopen them every time they need to store or retrieve data. This
-is because memcached is especially designed to work very efficiently
-with a very large number (many hundreds, more than a thousand if
-necessary) of open connections. Caching connections will eliminate the
-overhead associated with establishing a TCP connection (the overhead
-of preparing for a new connection on the server side is insignificant
-compared to this).
-
-There are two kinds of data sent in the memcache protocol: text lines
-and unstructured data. Text lines are used for commands from clients
-and responses from servers. Unstructured data is sent when a client
-wants to store or retrieve data. The server will transmit back
-unstructured data in exactly the same way it received it, as a byte
-stream. The server doesn't care about byte order issues in
-unstructured data and isn't aware of them. There are no limitations on
-characters that may appear in unstructured data; however, the reader
-of such data (either a client or a server) will always know, from a
-preceding text line, the exact length of the data block being
-transmitted.
-
-Text lines are always terminated by \r\n. Unstructured data is _also_
-terminated by \r\n, even though \r, \n or any other 8-bit characters
-may also appear inside the data. Therefore, when a client retrieves
-data from a server, it must use the length of the data block (which it
-will be provided with) to determine where the data block ends, and not
-the fact that \r\n follows the end of the data block, even though it
-does.
-
-Keys
-----
-
-Data stored by memcached is identified with the help of a key. A key
-is a text string which should uniquely identify the data for clients
-that are interested in storing and retrieving it. Currently the
-length limit of a key is set at 250 characters (of course, normally
-clients wouldn't need to use such long keys); the key must not include
-control characters or whitespace.
-
-Commands
---------
-
-There are three types of commands.
-
-Storage commands (there are six: "set", "add", "replace", "append"
-"prepend" and "cas") ask the server to store some data identified by a
-key. The client sends a command line, and then a data block; after
-that the client expects one line of response, which will indicate
-success or failure.
-
-Retrieval commands (there are two: "get" and "gets") ask the server to
-retrieve data corresponding to a set of keys (one or more keys in one
-request). The client sends a command line, which includes all the
-requested keys; after that for each item the server finds it sends to
-the client one response line with information about the item, and one
-data block with the item's data; this continues until the server
-finished with the "END" response line.
-
-All other commands don't involve unstructured data. In all of them,
-the client sends one command line, and expects (depending on the
-command) either one line of response, or several lines of response
-ending with "END" on the last line.
-
-A command line always starts with the name of the command, followed by
-parameters (if any) delimited by whitespace. Command names are
-lower-case and are case-sensitive.
-
-Expiration times
-----------------
-
-Some commands involve a client sending some kind of expiration time
-(relative to an item or to an operation requested by the client) to
-the server. In all such cases, the actual value sent may either be
-Unix time (number of seconds since January 1, 1970, as a 32-bit
-value), or a number of seconds starting from current time. In the
-latter case, this number of seconds may not exceed 60*60*24*30 (number
-of seconds in 30 days); if the number sent by a client is larger than
-that, the server will consider it to be real Unix time value rather
-than an offset from current time.
-
-
-Error strings
--------------
-
-Each command sent by a client may be answered with an error string
-from the server. These error strings come in three types:
-
-- "ERROR\r\n"
-
- means the client sent a nonexistent command name.
-
-- "CLIENT_ERROR <error>\r\n"
-
- means some sort of client error in the input line, i.e. the input
- doesn't conform to the protocol in some way. <error> is a
- human-readable error string.
-
-- "SERVER_ERROR <error>\r\n"
-
- means some sort of server error prevents the server from carrying
- out the command. <error> is a human-readable error string. In cases
- of severe server errors, which make it impossible to continue
- serving the client (this shouldn't normally happen), the server will
- close the connection after sending the error line. This is the only
- case in which the server closes a connection to a client.
-
-
-In the descriptions of individual commands below, these error lines
-are not again specifically mentioned, but clients must allow for their
-possibility.
-
-
-Storage commands
-----------------
-
-First, the client sends a command line which looks like this:
-
-<command name> <key> <flags> <exptime> <bytes> [noreply]\r\n
-cas <key> <flags> <exptime> <bytes> <cas unique> [noreply]\r\n
-
-- <command name> is "set", "add", "replace", "append" or "prepend"
-
- "set" means "store this data".
-
- "add" means "store this data, but only if the server *doesn't* already
- hold data for this key".
-
- "replace" means "store this data, but only if the server *does*
- already hold data for this key".
-
- "append" means "add this data to an existing key after existing data".
-
- "prepend" means "add this data to an existing key before existing data".
-
- The append and prepend commands do not accept flags or exptime.
- They update existing data portions, and ignore new flag and exptime
- settings.
-
- "cas" is a check and set operation which means "store this data but
- only if no one else has updated since I last fetched it."
-
-- <key> is the key under which the client asks to store the data
-
-- <flags> is an arbitrary 16-bit unsigned integer (written out in
- decimal) that the server stores along with the data and sends back
- when the item is retrieved. Clients may use this as a bit field to
- store data-specific information; this field is opaque to the server.
- Note that in memcached 1.2.1 and higher, flags may be 32-bits, instead
- of 16, but you might want to restrict yourself to 16 bits for
- compatibility with older versions.
-
-- <exptime> is expiration time. If it's 0, the item never expires
- (although it may be deleted from the cache to make place for other
- items). If it's non-zero (either Unix time or offset in seconds from
- current time), it is guaranteed that clients will not be able to
- retrieve this item after the expiration time arrives (measured by
- server time).
-
-- <bytes> is the number of bytes in the data block to follow, *not*
- including the delimiting \r\n. <bytes> may be zero (in which case
- it's followed by an empty data block).
-
-- <cas unique> is a unique 64-bit value of an existing entry.
- Clients should use the value returned from the "gets" command
- when issuing "cas" updates.
-
-- "noreply" optional parameter instructs the server to not send the
- reply. NOTE: if the request line is malformed, the server can't
- parse "noreply" option reliably. In this case it may send the error
- to the client, and not reading it on the client side will break
- things. Client should construct only valid requests.
-
-After this line, the client sends the data block:
-
-<data block>\r\n
-
-- <data block> is a chunk of arbitrary 8-bit data of length <bytes>
- from the previous line.
-
-After sending the command line and the data blockm the client awaits
-the reply, which may be:
-
-- "STORED\r\n", to indicate success.
-
-- "NOT_STORED\r\n" to indicate the data was not stored, but not
-because of an error. This normally means that the
-condition for an "add" or a "replace" command wasn't met.
-
-- "EXISTS\r\n" to indicate that the item you are trying to store with
-a "cas" command has been modified since you last fetched it.
-
-- "NOT_FOUND\r\n" to indicate that the item you are trying to store
-with a "cas" command did not exist.
-
-
-Retrieval command:
-------------------
-
-The retrieval commands "get" and "gets" operates like this:
-
-get <key>*\r\n
-gets <key>*\r\n
-
-- <key>* means one or more key strings separated by whitespace.
-
-After this command, the client expects zero or more items, each of
-which is received as a text line followed by a data block. After all
-the items have been transmitted, the server sends the string
-
-"END\r\n"
-
-to indicate the end of response.
-
-Each item sent by the server looks like this:
-
-VALUE <key> <flags> <bytes> [<cas unique>]\r\n
-<data block>\r\n
-
-- <key> is the key for the item being sent
-
-- <flags> is the flags value set by the storage command
-
-- <bytes> is the length of the data block to follow, *not* including
- its delimiting \r\n
-
-- <cas unique> is a unique 64-bit integer that uniquely identifies
- this specific item.
-
-- <data block> is the data for this item.
-
-If some of the keys appearing in a retrieval request are not sent back
-by the server in the item list this means that the server does not
-hold items with such keys (because they were never stored, or stored
-but deleted to make space for more items, or expired, or explicitly
-deleted by a client).
-
-
-Deletion
---------
-
-The command "delete" allows for explicit deletion of items:
-
-delete <key> [noreply]\r\n
-
-- <key> is the key of the item the client wishes the server to delete
-
-- "noreply" optional parameter instructs the server to not send the
- reply. See the note in Storage commands regarding malformed
- requests.
-
-The response line to this command can be one of:
-
-- "DELETED\r\n" to indicate success
-
-- "NOT_FOUND\r\n" to indicate that the item with this key was not
- found.
-
-See the "flush_all" command below for immediate invalidation
-of all existing items.
-
-
-Increment/Decrement
--------------------
-
-Commands "incr" and "decr" are used to change data for some item
-in-place, incrementing or decrementing it. The data for the item is
-treated as decimal representation of a 64-bit unsigned integer. If
-the current data value does not conform to such a representation, the
-incr/decr commands return an error (memcached <= 1.2.6 treated the
-bogus value as if it were 0, leading to confusing). Also, the item
-must already exist for incr/decr to work; these commands won't pretend
-that a non-existent key exists with value 0; instead, they will fail.
-
-The client sends the command line:
-
-incr <key> <value> [noreply]\r\n
-
-or
-
-decr <key> <value> [noreply]\r\n
-
-- <key> is the key of the item the client wishes to change
-
-- <value> is the amount by which the client wants to increase/decrease
-the item. It is a decimal representation of a 64-bit unsigned integer.
-
-- "noreply" optional parameter instructs the server to not send the
- reply. See the note in Storage commands regarding malformed
- requests.
-
-The response will be one of:
-
-- "NOT_FOUND\r\n" to indicate the item with this value was not found
-
-- <value>\r\n , where <value> is the new value of the item's data,
- after the increment/decrement operation was carried out.
-
-Note that underflow in the "decr" command is caught: if a client tries
-to decrease the value below 0, the new value will be 0. Overflow in
-the "incr" command will wrap around the 64 bit mark.
-
-Note also that decrementing a number such that it loses length isn't
-guaranteed to decrement its returned length. The number MAY be
-space-padded at the end, but this is purely an implementation
-optimization, so you also shouldn't rely on that.
-
-Touch
------
-
-The "touch" command is used to update the expiration time of an existing item
-without fetching it.
-
-touch <key> <exptime> [noreply]\r\n
-
-- <key> is the key of the item the client wishes the server to delete
-
-- <exptime> is expiration time. Works the same as with the update commands
- (set/add/etc). This replaces the existing expiration time. If an existing
- item were to expire in 10 seconds, but then was touched with an
- expiration time of "20", the item would then expire in 20 seconds.
-
-- "noreply" optional parameter instructs the server to not send the
- reply. See the note in Storage commands regarding malformed
- requests.
-
-The response line to this command can be one of:
-
-- "TOUCHED\r\n" to indicate success
-
-- "NOT_FOUND\r\n" to indicate that the item with this key was not
- found.
-
-Slabs Reassign
---------------
-
-NOTE: This command is subject to change as of this writing.
-
-The slabs reassign command is used to redistribute memory once a running
-instance has hit its limit. It might be desireable to have memory laid out
-differently than was automatically assigned after the server started.
-
-slabs reassign <source class> <dest class>\r\n
-
-- <source class> is an id number for the slab class to steal a page from
-
-A source class id of -1 means "pick from any valid class"
-
-- <dest class> is an id number for the slab class to move a page to
-
-The response line could be one of:
-
-- "OK" to indicate the page has been scheduled to move
-
-- "BUSY [message]" to indicate a page is already being processed, try again
- later.
-
-- "BADCLASS [message]" a bad class id was specified
-
-- "NOSPARE [message]" source class has no spare pages
-
-- "NOTFULL [message]" dest class must be full to move new pages to it
-
-- "UNSAFE [message]" source class cannot move a page right now
-
-- "SAME [message]" must specify different source/dest ids.
-
-Slabs Automove
---------------
-
-NOTE: This command is subject to change as of this writing.
-
-The slabs automove command enables a background thread which decides on its
-own when to move memory between slab classes. Its implementation and options
-will likely be in flux for several versions. See the wiki/mailing list for
-more details.
-
-The automover can be enabled or disabled at runtime with this command.
-
-slabs automove <0|1>
-
-- 0|1|2 is the indicator on whether to enable the slabs automover or not.
-
-The response should always be "OK\r\n"
-
-- <0> means to set the thread on standby
-
-- <1> means to run the builtin slow algorithm to choose pages to move
-
-- <2> is a highly aggressive mode which causes pages to be moved every time
- there is an eviction. It is not recommended to run for very long in this
- mode unless your access patterns are very well understood.
-
-Statistics
-----------
-
-The command "stats" is used to query the server about statistics it
-maintains and other internal data. It has two forms. Without
-arguments:
-
-stats\r\n
-
-it causes the server to output general-purpose statistics and
-settings, documented below. In the other form it has some arguments:
-
-stats <args>\r\n
-
-Depending on <args>, various internal data is sent by the server. The
-kinds of arguments and the data sent are not documented in this version
-of the protocol, and are subject to change for the convenience of
-memcache developers.
-
-
-General-purpose statistics
---------------------------
-
-Upon receiving the "stats" command without arguments, the server sents
-a number of lines which look like this:
-
-STAT <name> <value>\r\n
-
-The server terminates this list with the line
-
-END\r\n
-
-In each line of statistics, <name> is the name of this statistic, and
-<value> is the data. The following is the list of all names sent in
-response to the "stats" command, together with the type of the value
-sent for this name, and the meaning of the value.
-
-In the type column below, "32u" means a 32-bit unsigned integer, "64u"
-means a 64-bit unsigned integer. '32u.32u' means two 32-bit unsigned
-integers separated by a colon (treat this as a floating point number).
-
-|-----------------------+---------+-------------------------------------------|
-| Name | Type | Meaning |
-|-----------------------+---------+-------------------------------------------|
-| pid | 32u | Process id of this server process |
-| uptime | 32u | Number of secs since the server started |
-| time | 32u | current UNIX time according to the server |
-| version | string | Version string of this server |
-| pointer_size | 32 | Default size of pointers on the host OS |
-| | | (generally 32 or 64) |
-| rusage_user | 32u.32u | Accumulated user time for this process |
-| | | (seconds:microseconds) |
-| rusage_system | 32u.32u | Accumulated system time for this process |
-| | | (seconds:microseconds) |
-| curr_items | 32u | Current number of items stored |
-| total_items | 32u | Total number of items stored since |
-| | | the server started |
-| bytes | 64u | Current number of bytes used |
-| | | to store items |
-| curr_connections | 32u | Number of open connections |
-| total_connections | 32u | Total number of connections opened since |
-| | | the server started running |
-| connection_structures | 32u | Number of connection structures allocated |
-| | | by the server |
-| reserved_fds | 32u | Number of misc fds used internally |
-| cmd_get | 64u | Cumulative number of retrieval reqs |
-| cmd_set | 64u | Cumulative number of storage reqs |
-| cmd_flush | 64u | Cumulative number of flush reqs |
-| cmd_touch | 64u | Cumulative number of touch reqs |
-| get_hits | 64u | Number of keys that have been requested |
-| | | and found present |
-| get_misses | 64u | Number of items that have been requested |
-| | | and not found |
-| delete_misses | 64u | Number of deletions reqs for missing keys |
-| delete_hits | 64u | Number of deletion reqs resulting in |
-| | | an item being removed. |
-| incr_misses | 64u | Number of incr reqs against missing keys. |
-| incr_hits | 64u | Number of successful incr reqs. |
-| decr_misses | 64u | Number of decr reqs against missing keys. |
-| decr_hits | 64u | Number of successful decr reqs. |
-| cas_misses | 64u | Number of CAS reqs against missing keys. |
-| cas_hits | 64u | Number of successful CAS reqs. |
-| cas_badval | 64u | Number of CAS reqs for which a key was |
-| | | found, but the CAS value did not match. |
-| touch_hits | 64u | Numer of keys that have been touched with |
-| | | a new expiration time |
-| touch_misses | 64u | Numer of items that have been touched and |
-| | | not found |
-| auth_cmds | 64u | Number of authentication commands |
-| | | handled, success or failure. |
-| auth_errors | 64u | Number of failed authentications. |
-| evictions | 64u | Number of valid items removed from cache |
-| | | to free memory for new items |
-| reclaimed | 64u | Number of times an entry was stored using |
-| | | memory from an expired entry |
-| bytes_read | 64u | Total number of bytes read by this server |
-| | | from network |
-| bytes_written | 64u | Total number of bytes sent by this server |
-| | | to network |
-| limit_maxbytes | 32u | Number of bytes this server is allowed to |
-| | | use for storage. |
-| threads | 32u | Number of worker threads requested. |
-| | | (see doc/threads.txt) |
-| conn_yields | 64u | Number of times any connection yielded to |
-| | | another due to hitting the -R limit. |
-| hash_power_level | 32u | Current size multiplier for hash table |
-| hash_bytes | 64u | Bytes currently used by hash tables |
-| hash_is_expanding | bool | Indicates if the hash table is being |
-| | | grown to a new size |
-| expired_unfetched | 64u | Items pulled from LRU that were never |
-| | | touched by get/incr/append/etc before |
-| | | expiring |
-| evicted_unfetched | 64u | Items evicted from LRU that were never |
-| | | touched by get/incr/append/etc. |
-| slab_reassign_running | bool | If a slab page is being moved |
-| slabs_moved | 64u | Total slab pages moved |
-|-----------------------+---------+-------------------------------------------|
-
-Settings statistics
--------------------
-CAVEAT: This section describes statistics which are subject to change in the
-future.
-
-The "stats" command with the argument of "settings" returns details of
-the settings of the running memcached. This is primarily made up of
-the results of processing commandline options.
-
-Note that these are not guaranteed to return in any specific order and
-this list may not be exhaustive. Otherwise, this returns like any
-other stats command.
-
-|-------------------+----------+----------------------------------------------|
-| Name | Type | Meaning |
-|-------------------+----------+----------------------------------------------|
-| maxbytes | size_t | Maximum number of bytes allows in this cache |
-| maxconns | 32 | Maximum number of clients allowed. |
-| tcpport | 32 | TCP listen port. |
-| udpport | 32 | UDP listen port. |
-| inter | string | Listen interface. |
-| verbosity | 32 | 0 = none, 1 = some, 2 = lots |
-| oldest | 32u | Age of the oldest honored object. |
-| evictions | on/off | When off, LRU evictions are disabled. |
-| domain_socket | string | Path to the domain socket (if any). |
-| umask | 32 (oct) | umask for the creation of the domain socket. |
-| growth_factor | float | Chunk size growth factor. |
-| chunk_size | 32 | Minimum space allocated for key+value+flags. |
-| num_threads | 32 | Number of threads (including dispatch). |
-| stat_key_prefix | char | Stats prefix separator character. |
-| detail_enabled | bool | If yes, stats detail is enabled. |
-| reqs_per_event | 32 | Max num IO ops processed within an event. |
-| cas_enabled | bool | When no, CAS is not enabled for this server. |
-| tcp_backlog | 32 | TCP listen backlog. |
-| auth_enabled_sasl | yes/no | SASL auth requested and enabled. |
-| item_size_max | size_t | maximum item size |
-| maxconns_fast | bool | If fast disconnects are enabled |
-| hashpower_init | 32 | Starting size multiplier for hash table |
-| slab_reassign | bool | Whether slab page reassignment is allowed |
-| slab_automove | bool | Whether slab page automover is enabled |
-|-------------------+----------+----------------------------------------------|
-
-
-Item statistics
----------------
-CAVEAT: This section describes statistics which are subject to change in the
-future.
-
-The "stats" command with the argument of "items" returns information about
-item storage per slab class. The data is returned in the format:
-
-STAT items:<slabclass>:<stat> <value>\r\n
-
-The server terminates this list with the line
-
-END\r\n
-
-The slabclass aligns with class ids used by the "stats slabs" command. Where
-"stats slabs" describes size and memory usage, "stats items" shows higher
-level information.
-
-The following item values are defined as of writing.
-
-Name Meaning
-------------------------------
-number Number of items presently stored in this class. Expired
- items are not automatically excluded.
-age Age of the oldest item in the LRU.
-evicted Number of times an item had to be evicted from the LRU
- before it expired.
-evicted_nonzero Number of times an item which had an explicit expire
- time set had to be evicted from the LRU before it
- expired.
-evicted_time Seconds since the last access for the most recent item
- evicted from this class. Use this to judge how
- recently active your evicted data is.
-outofmemory Number of times the underlying slab class was unable to
- store a new item. This means you are running with -M or
- an eviction failed.
-tailrepairs Number of times we self-healed a slab with a refcount
- leak. If this counter is increasing a lot, please
- report your situation to the developers.
-reclaimed Number of times an entry was stored using memory from
- an expired entry.
-expired_unfetched Number of expired items reclaimed from the LRU which
- were never touched after being set.
-evicted_unfetched Number of valid items evicted from the LRU which were
- never touched after being set.
-
-Note this will only display information about slabs which exist, so an empty
-cache will return an empty set.
-
-
-Item size statistics
---------------------
-CAVEAT: This section describes statistics which are subject to change in the
-future.
-
-The "stats" command with the argument of "sizes" returns information about the
-general size and count of all items stored in the cache.
-WARNING: This command WILL lock up your cache! It iterates over *every item*
-and examines the size. While the operation is fast, if you have many items
-you could prevent memcached from serving requests for several seconds.
-
-The data is returned in the following format:
-
-<size> <count>\r\n
-
-The server terminates this list with the line
-
-END\r\n
-
-'size' is an approximate size of the item, within 32 bytes.
-'count' is the amount of items that exist within that 32-byte range.
-
-This is essentially a display of all of your items if there was a slab class
-for every 32 bytes. You can use this to determine if adjusting the slab growth
-factor would save memory overhead. For example: generating more classes in the
-lower range could allow items to fit more snugly into their slab classes, if
-most of your items are less than 200 bytes in size.
-
-
-Slab statistics
----------------
-CAVEAT: This section describes statistics which are subject to change in the
-future.
-
-The "stats" command with the argument of "slabs" returns information about
-each of the slabs created by memcached during runtime. This includes per-slab
-information along with some totals. The data is returned in the format:
-
-STAT <slabclass>:<stat> <value>\r\n
-STAT <stat> <value>\r\n
-
-The server terminates this list with the line
-
-END\r\n
-
-|-----------------+----------------------------------------------------------|
-| Name | Meaning |
-|-----------------+----------------------------------------------------------|
-| chunk_size | The amount of space each chunk uses. One item will use |
-| | one chunk of the appropriate size. |
-| chunks_per_page | How many chunks exist within one page. A page by |
-| | default is less than or equal to one megabyte in size. |
-| | Slabs are allocated by page, then broken into chunks. |
-| total_pages | Total number of pages allocated to the slab class. |
-| total_chunks | Total number of chunks allocated to the slab class. |
-| get_hits | Total number of get requests serviced by this class. |
-| cmd_set | Total number of set requests storing data in this class. |
-| delete_hits | Total number of successful deletes from this class. |
-| incr_hits | Total number of incrs modifying this class. |
-| decr_hits | Total number of decrs modifying this class. |
-| cas_hits | Total number of CAS commands modifying this class. |
-| cas_badval | Total number of CAS commands that failed to modify a |
-| | value due to a bad CAS id. |
-| touch_hits | Total number of touches serviced by this class. |
-| used_chunks | How many chunks have been allocated to items. |
-| free_chunks | Chunks not yet allocated to items, or freed via delete. |
-| free_chunks_end | Number of free chunks at the end of the last allocated |
-| | page. |
-| mem_requested | Number of bytes requested to be stored in this slab[*]. |
-| active_slabs | Total number of slab classes allocated. |
-| total_malloced | Total amount of memory allocated to slab pages. |
-|-----------------+----------------------------------------------------------|
-
-* Items are stored in a slab that is the same size or larger than the
- item. mem_requested shows the size of all items within a
- slab. (total_chunks * chunk_size) - mem_requested shows memory
- wasted in a slab class. If you see a lot of waste, consider tuning
- the slab factor.
-
-Other commands
---------------
-
-"flush_all" is a command with an optional numeric argument. It always
-succeeds, and the server sends "OK\r\n" in response (unless "noreply"
-is given as the last parameter). Its effect is to invalidate all
-existing items immediately (by default) or after the expiration
-specified. After invalidation none of the items will be returned in
-response to a retrieval command (unless it's stored again under the
-same key *after* flush_all has invalidated the items). flush_all
-doesn't actually free all the memory taken up by existing items; that
-will happen gradually as new items are stored. The most precise
-definition of what flush_all does is the following: it causes all
-items whose update time is earlier than the time at which flush_all
-was set to be executed to be ignored for retrieval purposes.
-
-The intent of flush_all with a delay, was that in a setting where you
-have a pool of memcached servers, and you need to flush all content,
-you have the option of not resetting all memcached servers at the
-same time (which could e.g. cause a spike in database load with all
-clients suddenly needing to recreate content that would otherwise
-have been found in the memcached daemon).
-
-The delay option allows you to have them reset in e.g. 10 second
-intervals (by passing 0 to the first, 10 to the second, 20 to the
-third, etc. etc.).
-
-
-"version" is a command with no arguments:
-
-version\r\n
-
-In response, the server sends
-
-"VERSION <version>\r\n", where <version> is the version string for the
-server.
-
-"verbosity" is a command with a numeric argument. It always succeeds,
-and the server sends "OK\r\n" in response (unless "noreply" is given
-as the last parameter). Its effect is to set the verbosity level of
-the logging output.
-
-"quit" is a command with no arguments:
-
-quit\r\n
-
-Upon receiving this command, the server closes the
-connection. However, the client may also simply close the connection
-when it no longer needs it, without issuing this command.
-
-
-UDP protocol
-------------
-
-For very large installations where the number of clients is high enough
-that the number of TCP connections causes scaling difficulties, there is
-also a UDP-based interface. The UDP interface does not provide guaranteed
-delivery, so should only be used for operations that aren't required to
-succeed; typically it is used for "get" requests where a missing or
-incomplete response can simply be treated as a cache miss.
-
-Each UDP datagram contains a simple frame header, followed by data in the
-same format as the TCP protocol described above. In the current
-implementation, requests must be contained in a single UDP datagram, but
-responses may span several datagrams. (The only common requests that would
-span multiple datagrams are huge multi-key "get" requests and "set"
-requests, both of which are more suitable to TCP transport for reliability
-reasons anyway.)
-
-The frame header is 8 bytes long, as follows (all values are 16-bit integers
-in network byte order, high byte first):
-
-0-1 Request ID
-2-3 Sequence number
-4-5 Total number of datagrams in this message
-6-7 Reserved for future use; must be 0
-
-The request ID is supplied by the client. Typically it will be a
-monotonically increasing value starting from a random seed, but the client
-is free to use whatever request IDs it likes. The server's response will
-contain the same ID as the incoming request. The client uses the request ID
-to differentiate between responses to outstanding requests if there are
-several pending from the same server; any datagrams with an unknown request
-ID are probably delayed responses to an earlier request and should be
-discarded.
-
-The sequence number ranges from 0 to n-1, where n is the total number of
-datagrams in the message. The client should concatenate the payloads of the
-datagrams for a given response in sequence number order; the resulting byte
-stream will contain a complete response in the same format as the TCP
-protocol (including terminating \r\n sequences).
projects / awesomized / libmemcached / blobdiff