Skip to content

Conversation

@wenyongh
Copy link
Collaborator

No description provided.

loganek and others added 4 commits July 28, 2022 12:25
Implement wasi_addr_resolve function.
    
Also slightly modify the interface to make it more accessible for the end user:
- replace port argument with the service - so the user can actually get the port for a given service if unknown
- introduce __wasi_addr_info_t and use it as a buffer for addresses, instead of generic buffer
- introduce __wasi_addr_info_hints_t so user can enable filtering on the syscall level (and therefore use smaller buffers for addresses)
- add max_size parameter for the API as an output - in case the number of addresses is bigger than the buffer size, user can repeat the call with bigger buffer

This change is very minimalistic, and it doesn't include the followings:
 1. implementation of getaddrinfo in the lib-socket
 2. sample application
Which are to be added in the following change #1336
…1327)

Fix socket-api byte order issue for systems where host byte order
and network byte order are the same:
- Document data structures used for storing IP addresses
- Fix bug in bind and connect methods by updating code in wasi_socket_ext
Slightly change the __wasi_sock_addr_local interface - since we already have
a `__wasi_addr_t` structure which is an union, there's no need for passing the
length around - the address buffer will always have the right length (i.e. max
of all address families).
Slightly changed the interface sock_addr_remote - since we already
have a `__wasi_addr_t` structure which is an union, there's no need
for passing length around - the address buffer will always have the
right length (i.e. max of all address families).
@wenyongh
Copy link
Collaborator Author

@loganek Are there any PRs to submit to dev/socket recently? Shall we merge the changes from dev/socket into main firstly, since we are planning to release a new version of WAMR. Wandering whether it is a big impact to current socket api user?
@lum1n0us What is your opinion?

@loganek
Copy link
Contributor

loganek commented Aug 19, 2022

We'll definitely have more PRs for sockets, but none of the changes we have in the branch are breaking WAMR so I think it's safe to merge. Having said that, please don't remove the dev/socket branch as we'll be sending few more PRs (for ipv6, some of the socket properties, add getaddrinfo implementation in socket libc etc.)

@lum1n0us
Copy link
Contributor

Tend to keep all modifications on dev/socket until all PRs and features(ipv6, socket properties, and so on) are ready.

@wenyongh wenyongh marked this pull request as draft August 22, 2022 06:26
@wenyongh
Copy link
Collaborator Author

wenyongh commented Aug 22, 2022

Some of the changes really impact the current wasm app, for example, the implementation of wasi_sock_ext is changed, which will be linked into wasm app, and the signatures of sock_addr_local/sock_addr_remote/sock_addr_resolve are also changed. These mean that the old wasm app cannot correctly run in the current runtime.
@loganek @lum1n0us How about we keep the socket API unchanged in the next release? And merge this PR after the new version is released?

@loganek
Copy link
Contributor

loganek commented Aug 22, 2022

the signatures of sock_addr_local/sock_addr_remote/sock_addr_resolve

@wenyongh I understand your concerns and I agree those APIs have changed. However, they did not have the implementation, so I'm not sure if there's a serious risk in releasing those - not only they didn't have an implementation, but they were also not exposed through wasi_sock_ext so not sure if there was any usecase of those functions?

Having said that, I don't mind waiting with the merge until all the changes we're waiting for are merged to dev/socket. I guess we can have another WAMR release shortly after we merge dev/socket into main?

@wenyongh
Copy link
Collaborator Author

the signatures of sock_addr_local/sock_addr_remote/sock_addr_resolve

@wenyongh I understand your concerns and I agree those APIs have changed. However, they did not have the implementation, so I'm not sure if there's a serious risk in releasing those - not only they didn't have an implementation, but they were also not exposed through wasi_sock_ext so not sure if there was any usecase of those functions?

Having said that, I don't mind waiting with the merge until all the changes we're waiting for are merged to dev/socket. I guess we can have another WAMR release shortly after we merge dev/socket into main?

@loganek Yes, thanks for your understanding, my concern is that the current wasm app compiled with recent commits (from WAMR-05-18-2022 to current commit in main branch) cannot correctly run with the runtime compiled with dev/socket, developer may complain about the compatibility, though he can recompile the wasm app to resolve the issue.
And yes, it seems a good idea to create a release without dev/socket PRs, and then create another release with dev/socket some time later. @lum1n0us What is you opinion? Is that OK?

@lum1n0us
Copy link
Contributor

agree with that it is a riskless option to release without dev/socket.

loganek and others added 11 commits September 1, 2022 22:20
For now this implementation only covers posix platforms, as defined in MVP #1336
The ns-lookup accepts domain names as well as suffixes, e.g.:

```
--allow-resolve=* # allow all domain names
--allow-resolve=example.com # only allow example.com name resolution
--allow-resolve=example.com --allow-resolve=*.example.com # allow example.com and its subdomains' name resolution
```
So getaddrinfo() can be used when compiling wasm app of C programs.
Added socket send and recv timeout options with implementation for posix platform.

This is part of a extending support for sockets in WASI. #1336.

Also add sample that sets and reads back the send and receive timeouts using
the native function binding.
Add a group of socket options used by cURL and rust stdlib, as well as some UDP multicast options.
#1490)

For some implementations (e.g. Mac OS) `bind()` requires the length to be exactly
equal to either `sockaddr_in` or `sockaddr_in6` structure. Because we always used
 `sizeof(struct sockaddr_storage)`, `bind()` was returning errors. In this change we
 fix the behavior. See StackOverflow [1] for details.

[1] https://stackoverflow.com/questions/73707162/socket-bind-failed-with-invalid-argument-error-for-program-running-on-macos
This also fixes debug build
…1497)

**What**

* Updated `copy_buffer_to_iovec_app` so that it copies as much of the buffer into the iovec as specified
* Throw invalid value when allocating an iovec of size 0

**Why**

* A bug found from TCP client example which allocates 1024 for the iovec size (where the buf size is also 1024) but received bytes is passed in as the `buf_size` argument to `copy_buffer_to_iovec_app`. This would return early after hitting this check `buf + data->buf_len > buf_begin + buf_size`. However, if the amount to copy is less than the iovec size, we should copy that much of the buf size. Eg TCP client sample receives 27(?) bytes at a time, and this copies 27 bytes into the iovec of size 1024
* The TCP client example attempts to recv bytes of size 0, this attempts to wasm malloc size 0, which outputs a warning. We should early return if recv bytes of size 0
@loganek
Copy link
Contributor

loganek commented Sep 22, 2022

We've internally performed the tests and the PR is ready for review and merge. @wenyongh could you remove a draft flag from the PR and have a look? Thanks.

@wenyongh wenyongh marked this pull request as ready for review September 22, 2022 10:31
@wenyongh wenyongh merged commit 78b5c5b into main Sep 22, 2022
vickiegpt pushed a commit to vickiegpt/wamr-aot-gc-checkpoint-restore that referenced this pull request May 27, 2024
Implement more socket APIs, refer to bytecodealliance#1336 and below PRs:
- Implement wasi_addr_resolve function (bytecodealliance#1319)
- Fix socket-api byte order issue when host/network order are the same (bytecodealliance#1327)
- Enhance sock_addr_local syscall (bytecodealliance#1320)
- Implement sock_addr_remote syscall (bytecodealliance#1360)
- Add support for IPv6 in WAMR (bytecodealliance#1411)
- Implement ns lookup allowlist (bytecodealliance#1420)
- Implement sock_send_to and sock_recv_from system calls (bytecodealliance#1457)
- Added http downloader and multicast socket options (bytecodealliance#1467)
- Fix `bind()` calls to receive the correct size of `sockaddr` structure (bytecodealliance#1490)
- Assert on correct parameters (bytecodealliance#1505)
- Copy only received bytes from socket recv buffer into the app buffer (bytecodealliance#1497)

Co-authored-by: Marcin Kolny <mkolny@amazon.com>
Co-authored-by: Marcin Kolny <marcin.kolny@gmail.com>
Co-authored-by: Callum Macmillan <callumimacmillan@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants