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).
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.
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.
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 .
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
Last updated: Nov 22 2024 at 16:03 UTC