Error in Protocol Docs?

[Brad Fitzpatrick]

Docs updated.


On Sat, 28 Apr 2007, Alex Stapleton 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
> >>
> >>
> >>
>
>