Skip to content

Byte order for arguments #57

Description

@mfalt

I think there is something wrong with how https://github.com/JuliaComputing/AMQPClient.jl/ encodes extra arguments, but I cant figure out exactly what.
You can try it yourself with something like
queue_declare(CHANNEL, QUEUE_NAME, arguments=Dict{String,Any}("x-expires"=>12345))
which by rabbit gets interpreted as a much larger number (close to the max of an Int64. I get similar problems if i try to send an Int32 or Int16)

The pattern I can find seems to be that the bytes are in some reversed order. Two examples with
n_julia => n_rabbit
12345 => 959447040
54321 => 835977216
If we look at the binary representations (32bit):
00000000000000000011000000111001 => 00111001001100000000000000000000
00000000000000001101010000110001 => 00110001110101000000000000000000

It seems that the conversion is something like

> bitstring(Int32(12345)) |> ( x -> String([x[25:32]...;x[17:24]...;x[9:16]...;x[1:8]...]) ) == bitstring(Int32(959447040))
true
> bitstring(Int32(54321)) |> ( x -> String([x[25:32]...;x[17:24]...;x[9:16]...;x[1:8]...]) ) == bitstring(Int32(835977216))
true

PS: Some more research seems to indicate that it is actually a case of endian-ness "AMQP uses network byte order for all numeric values", so
bswap(Int32(12345)) == 959447040
and the following works:
queue_declare(CHANNEL, QUEUE_NAME, arguments=Dict{String,Any}("x-expires"=>bswap(Int32(12345))))

Edit: Seems that there are a lot of calls to hton in the code, so it is probably just missing or done twice for integer arguments.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions