Error in Protocol Docs?

[Marc]

At least going back to 07/2005, add/set/replace commands were parsed with a
sscanf like:
                 res = sscanf(command, "%*s %250s %u %ld %d\n", key, &flags,
                              &expire, &len);

I changed that to use strtoul as part of the string tokenization performance
improvements.  I just kept the types as they had been and didn't catch that
protocol.txt specified an unsigned 16 bit flag field.  I think it's
reasonable  to change the spec to 32 bit since that is in fact what's
supported.  

The only danger is for installations have a mix of clients; some that handle
32 bit integers and some that don't.  In that case a set by a 32-bit-flag
client may not be properly retrieved by a 16-bit-flag client (either the
upper 16 bits will be dropped or it will be treated as a protocol error.)
In fact, that problem can exist right now, so standardizing everything on 32
bit flags is the right call.


On 4/28/07 11:02 AM, "Alex Stapleton" <alexs at advfn.com> wrote:

> 
> 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 advfn.com
>>> T: 0207 0700 956
>>> 
>>> 
>>> 
>