Stream: wamr

Topic: Endiannes of __wasi_addr_ip6_t elements


view this post on Zulip Marcin Kolny (Jul 23 2022 at 11:50):

Hi all, I'm currently working on enabling IPv6 in WAMR sockets and one thing that wasn't clear to me is the expected endianness for n0,n1,... fields in the __wasi_addr_ip6_t structure. Is this expected to be a host byte order or network byte order (i.e. big endian)? If that's not decided, my suggestion is to keep it big endian so we're consistent with POSIX, although I'd like to hear your thoughts.
Having it always the same byte order (regardless of the host) I think would simplify a lot of operations (e.g. if we want to implement ipv6 for address pool, with host byte order we'd have to have two branches for different byte orders).

view this post on Zulip Marcin Kolny (Jul 23 2022 at 12:28):

Also, I noticed some of the code might be a bit confusing at the first look; for example, in ipv4 structure n3 is the most significant byte (according for example to this code). However, the way we construct an address in bind is actually opposite (n3 is the last part, so ). The example code (tcp_client.c) works well, because we convert localhost address to host byte order whereas it should be a network byte order in the sin_addr structure (see documentation for details). I'm going to fix all this inconsistency, document clearly the data structures that are ambiguous and open a PR for that.

WebAssembly Micro Runtime (WAMR). Contribute to bytecodealliance/wasm-micro-runtime development by creating an account on GitHub.
WebAssembly Micro Runtime (WAMR). Contribute to bytecodealliance/wasm-micro-runtime development by creating an account on GitHub.

view this post on Zulip lum1n0us (Jul 25 2022 at 05:15):

Hi,
I agreed with the idea about keeping the same byte order with POSIX.

Yes, it is a little wired that n3 is not always the most significant byte. Thanks for volunteer.

view this post on Zulip Marcin Kolny (Jul 25 2022 at 08:55):

Ok I think I know what the problem with my confusion was - I noticed that the code in wasi_socket_ext.c always assumes that host byte order != network byte order. I'm updating the code so it works on both little endian and big endian systems. Also, after having second thought about byte order in IPv6, I think it'd be actually best to go for host byte order - whereas that might add complexity to WAMR implementation, that seems to be more end-user friendly .

view this post on Zulip Marcin Kolny (Jul 25 2022 at 09:02):

I've opened a PR where I updated the documentation and fixed translation wasi address and posix address: https://github.com/bytecodealliance/wasm-micro-runtime/pull/1327

Documented data structures used for storing IP addresses. Fixed bug in bind and connect methods by updating a code in wasi_socket_ext.

Last updated: Oct 23 2024 at 20:03 UTC