Verify Endianness of connect token ipv6 addresses about netcode HOT 6 CLOSED

What does the ipv6 address data look like as an array of bytes in the connect token that you generate?

from netcode.

I would expect the array of bytes should look like:

0x00000000000000000000000000000100

Which when read into a uint16_t should look like:

0x0001 in the uint16 value?

from netcode.

(because little endian switches byte order from a uint16 when its read in from memory, while big endian does not... but for both little endian and big endian, the format of a uint16_t in register is the same).

from netcode.

So net.IP (which stores the ip address as a series of bytes) shows:
net.IP{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1}
the code i use to write/serialize it to the connect token buffer:

for i := 0; i < len(parsed); i += 2 {
    var n uint16
    n = binary.BigEndian.Uint16([]byte(parsed[i : i+2]))
        buffer.WriteUint16(n)
}

shows: []byte{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0}
if i change the binary.BigEndian.Uint16 to binary.LittleEndian.Uint16(...) i get:
[]byte{0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1}
(Note that buffer.WriteUint16(n) does the following):

b.Buf[b.Pos] = byte(n)
b.Pos++
b.Buf[b.Pos] = byte(n >> 8)
b.Pos++

from netcode.

So giving this some more thought, I think the reason is completely on my side, since net.IP already stores it in big endian, converting those bytes again to big endian again actually flips it back to being little endian. We can probably close this.

from netcode.

Makes sense. There are similar endian issues in the C API for parsing IP addresses too, it's tricky.

from netcode.