Alignment in the binary protocol

[Trond Norbye]

On Mar 18, 2008, at 2:54 PM, Brian Aker wrote:

> Hi!
>
> So I have not looked at the code yet concerning this bit.... Is the  
> code safe from byte alignment problems between different endian  
> hosts/clients?
>

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  
right now):

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..

Trond


> Cheers,
> 	-Brian
>
> On Mar 18, 2008, at 4:59 AM, Trond Norbye wrote:
>
>> Hi,
>>
>> 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  
>> uint64_t...
>>
>> 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  
>> this.
>>
>> Trond
>>
>> <alignment.patch.gz>
>
> --
> _______________________________________________________
> Brian "Krow" Aker, brian at tangent.org
> Seattle, Washington
> http://krow.net/                     <-- Me
> http://tangent.org/                <-- Software
> _______________________________________________________
> You can't grep a dead tree.
>
>
>