Error in Protocol Docs?

Alex Stapleton alexs at
Sat Apr 28 18:02:13 UTC 2007

On 28 Apr 2007, at 17:36, Brad Fitzpatrick wrote:

> Historically, at least, it was only 16 bits.  It might only be 16 bits
> currently on accident, and might be truncated back to 16 bits in the
> future if we go on another struct item packing mission.
> But yeah -- perhaps we should do a range check on it to prevent people
> from getting bitten?
> Does anybody remember when this changed from 16 bit to 32 bit, and if
> there was a good reason?

It's actually rather useful for us, i'd much rather you kept it at 32- 
bits, or offered it as an option to ./configure at least :)

We cache data both locally to each node using eaccelerator and also  
across the cluster with memcached. Basically we need to keep the ttls  
between memcached and the local caches in sync so we store the expiry  
time of the key in the flags field on memcached and then recalculate  
the expiry time on retrieval before it's added to eaccelerator.

OT: oh btw, has anyone else noticed that PHP doesn't have an unsigned  
int data type? I hope they fix that before the epoch hits 2147483647...

> On Sat, 28 Apr 2007, Alex Stapleton wrote:
>> - <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.
>> However looking at the source, and testing it out myself, this
>> appears to be a lie. unsigned 32-bit ints appear to be used to store
>> flags with no range checks which means it works just fine if you
>> store 32-bit values in there. afaict the high 16-bits aren't used for
>> anything internally either. Is this right? Is it safe to use values
>>> 65535 in the flags field of a key? Being able to stick a 32-bit
>> value in there certainly is rather handy with the rather unusual
>> configuration we are using :)
>> Alex Stapleton
>> alexs at
>> T: 0207 0700 956

More information about the memcached mailing list