search

second-state / wasmedge_wasi_socket

A Rust lib for socket on WasmEdge.
https://second-state.github.io/wasmedge_wasi_socket/
Apache License 2.0
70 stars 29 forks source link

WasmEdge broke ABI of sock_getlocaladdr and sock_getpeeraddr #81

Open achille-roussel opened 1 year ago

achille-roussel commented 1 year ago

Hello!

I was working this this library and I noticed that the changes from https://github.com/WasmEdge/WasmEdge/pull/1599 have changed the signatures of socket_getlocaladdr and sock_getpeeraddr. As far as I can tell, all programs built with wasmedge_wasi_socket (or other that were ABI compatible) won't be able to run anymore if they depended on the socket extensions.

Ideally the runtime should not break ABIs, but since this seems to have been merged already, would it make sense to update this client library so programs that use it can run on WasmEdge and benefit from the socket extensions again?

For example, these functions would need to be updated so their signatures match what the runtime expects? https://github.com/second-state/wasmedge_wasi_socket/blob/main/src/socket.rs#L323-L334

hydai commented 1 year ago

We will have other breaking changes in the WasmEdge 0.12 release, e.g. sync up the spec with the WASI socket spec at the same time. So this and the related libraries will be updated once the ABI is fixed. There will be a new version for this.

juntao commented 1 year ago

Hi @achille-roussel

The WasmEdge WASI socket aims to support more features over time (eg DNS, Domain sockets, TLS). So, we can only guarantee compatibility with specific WasmEdge release versions. For example, the wasmedge_wasi_socket 0.4.x are compatible with WasmEdge 0.11.x.

If you can tell us more about your specific use cases, we will be able to give more specific suggestions on how to stay compatible. Thanks!

achille-roussel commented 1 year ago

Would it be possible for WasmEdge to introduce these extensions in a backward-compatible manner? For example, having sock_getpeeraddr then sock_getpeeraddr2 similarly to how the Linux kernel introduces new versions of syscalls?

As a user, it is difficult to keep up with these types of changes because they may appear late in the development process (e.g. if the wasmedge version in a production environment happens not to be the same as the one used during tests).

juntao commented 1 year ago

It is certainly the way to do it once we reach a stable 1.0 release.

Our current priority is to reach feature parity with Linux sockets. At the same time, we also need to accommodate changes in the draft WASI socket spec so that we can stay compatible with other Wasm runtimes. So things might change from release to release.

Is it possible for you to lock down the wasmedge_wasi_socket version and WasmEdge runtime version for your project so that they do not break when we release new features? Thanks!