Lines Matching refs:client
10 There is no need to send any command to end the session. A client may
23 and responses from servers. Unstructured data is sent when a client
29 of such data (either a client or a server) will always know, from a
35 may also appear inside the data. Therefore, when a client retrieves
58 key. The client sends a command line, and then a data block; after
59 that the client expects one line of response, which will indicate
64 request). The client sends a command line, which includes all the
66 the client one response line with information about the item, and one
71 the client sends one command line, and expects (depending on the
89 Meta flags are not to be confused with client bitflags, which is an opaque
90 number passed by the client. Meta flags change how the command operates, but
128 proxy or router inbetween a client and a memcached daemon. For example, a
129 client may prepend a "path" in the key itself: "mg /path/foo v" or in a proxy
142 Some commands involve a client sending some kind of expiration time
143 (relative to an item or to an operation requested by the client) to
148 of seconds in 30 days); if the number sent by a client is larger than
159 Each command sent by a client may be answered with an error string
164 means the client sent a nonexistent command name.
168 means some sort of client error in the input line, i.e. the input
177 serving the client (this shouldn't normally happen), the server will
179 case in which the server closes a connection to a client.
207 First, the client sends a command line which looks like this:
233 - <key> is the key under which the client asks to store the data
262 to the client, and not reading it on the client side will break
265 After this line, the client sends the data block:
272 After sending the command line and the data block the client awaits
298 After this command, the client expects zero or more items, each of
327 deleted by a client).
337 - <key> is the key of the item the client wishes the server to delete
366 The client sends the command line:
374 - <key> is the key of the item the client wishes to change
376 - <value> is the amount by which the client wants to increase/decrease
390 Note that underflow in the "decr" command is caught: if a client tries
407 - <key> is the key of the item the client wishes the server to touch
438 After this command, the client expects zero or more items, each of
508 After this command, the client expects an item to be returned, received as a
515 deleted by a client).
545 - f: return client flags token
563 - W: client has "won" the recache flag
576 signals to the client that the key is base64 encoded binary.
601 the client for normal responses. In the case of metaget, if an item is not
635 created a 'W' flag is added to the response to indicate to a client that they
640 Further requests will see a 'Z' flag to indicate that another client has
648 below the supplied token, return a 'W' flag to indicate the client has "won"
658 - W: client has "won" the recache flag
660 When combined with N or R flags, a client may be informed they have "won"
661 ownership of a cache item. This allows a single client to be atomically
672 client that an object needs to be updated, and that it should make a decision
680 When combined with the X flag, or the client N or R flags, this extra response
681 flag indicates to a client that a different client is responsible for
682 recaching this item. If there is data supplied it may use it, or the client
701 After this line, the client sends the data block:
709 After sending the command line and the data block the client awaits
733 - F(token): set client flags to token (32 bit unsigned numeric)
756 - F(token): set client flags to token (32 bit unsigned numeric)
771 the client for normal responses. In the case of metaset, a response that
844 it as stale. This means when it is later fetched by metaget, the client will
971 "MN\r\n", signalling to a client that all previous commands have been
1247 returned to a client while in proxy mode. The conditions which logs are
1530 | client_flags_size | 32u | Size in bytes of client flags |
1778 | ssl_proto_errors | 64u | Number of times a client has |
1781 | | | for client handshakes. |
1855 connection. However, the client may also simply close the connection
1900 The request ID is supplied by the client. Typically it will be a
1901 monotonically increasing value starting from a random seed, but the client
1903 contain the same ID as the incoming request. The client uses the request ID
1910 datagrams in the message. The client should concatenate the payloads of the