From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-09-23T03:26:17+09:00
Subject: Re: 64-bit integers in network byte-order

On 9/22/06, Young Hyun <youngh@caida.org> wrote:
 > Funny, I wrote almost exactly the above code just recently.  But, it
> may not be necessary.  Depending on your situation, you might
> consider using the "w" (BER-compressed integer) packing directive
> instead.  It guarantees that arbitrarily long integers are stored in
> a standard way (big endian).  The caveats are (1) it produces
> variable-length packed strings and (2) it only supports positive
> integers.  However, because BER-compressed integers are self-
> describing, in the sense that you can determine when you've reached
> the end of the encoded string, you could get around the first
> limitation (if it proves to be a limitation for your usage scenario)
> by left justifying the BER-compressed integer in a fixed field.  For
> my situation, I just changed the definition of my wire protocol to
> support variable-length "w"-encoded strings and didn't bother left
> justifying.
>


Thanks for the suggestion, but I'm having to interoperate with a wire
protocol (AMQP) that defines certain fields as eight-octet integers in
network-order, so I don't have a choice in the matter. Clearly
BER-encoding has the advantage of permitting nearly-arbitrary size,
but I think what has happened here is that the protocol designers are
heavily Java-centric, and eight-octets-in-network-order is Java's
native encoding for a long int.