Alignment in the binary protocol
Trond.Norbye at Sun.COM
Tue Mar 18 16:00:18 UTC 2008
On Mar 18, 2008, at 2:54 PM, Brian Aker wrote:
> So I have not looked at the code yet concerning this bit.... Is the
> code safe from byte alignment problems between different endian
I am not sure that I understand your question, but the uint64_t is
transferred in network byte order..
the problematic code looks somewhat like (i don't have the source here
uint64_t *cas = packet + headersize + 4;
*cas = swap64(item->cas_id);
This section could be rewritten to:
uint64_t cas = swap64(item->cas_id);
memcpy(packet + headersize + 4, &cas, 8)
But since both fields are mandatory and we are currently working on
finishing the first version of the binary protocol, I don't see why
not just swap the order of the flag and the cas....
Hope this answers your question..
> On Mar 18, 2008, at 4:59 AM, Trond Norbye wrote:
>> I have been testing the binary protocol the last few days and I
>> would like to suggest that we swap the order some fields to solve
>> some alignment problems.
>> The cas-id is a 64-bit datatype and will require 8-byte alignment
>> on some hardware, but it is placed on a 4-byte alignment in the get
>> response. The current get-response contains a 16 byte header
>> followed by the 4 byte flags-field causing the wrong alignment for
>> the cas id. If we swap the order on the two fields the cas-id will
>> get proper alignment, and we can access the field directly as an
>> To be consistent I suggest that we move the cas-id to the front in
>> the set/add/replace command as well. The attached patch implements
> Brian "Krow" Aker, brian at tangent.org
> Seattle, Washington
> http://krow.net/ <-- Me
> http://tangent.org/ <-- Software
> You can't grep a dead tree.
More information about the memcached