Yay! I managed to create a new topic!
@Guy Bedford please let me know If I am heading in the right direction: https://github.com/bytecodealliance/jco/pull/214
@Wassim Chegham nice start that's definitely the right track!
awesome! Thanks @Guy Bedford
bless you people
Q: are we supposed to write our own implementations for wasi-sockets, or use node:net, node:dgram, etc?
Ralph said:
bless you people
Hi @Ralph :wave:
Wassim Chegham said:
Q: are we supposed to write our own implementations for wasi-sockets, or use node:net, node:dgram, etc?
We should be reusing node:net
, node:dgram
, etc. for this. The way we're implementing this is by "virtualizing" the Wasi Preview 2 syscalls, backing them with Node's built-ins.
Eventually the plan is to move these bindings from being a virtualized JS layer to the uvwasi project directly. But that will require some work to implement, upstream, and validate. It's all C++, and we'd need to not only land this in uvwasi
but also upstream it to Node.js proper. So we're essentially punting on that and thinking of it as just an optimization.
@Wassim Chegham oh by the way, the sockets
API is one of the biggest surface areas of Wasi (52 methods). Doing it all in a single PR might be a lot, so please feel free to like file multiple PRs. That might make it easier to validate, review, test, etc.
Thanks @Yoshua Wuyts that was my understanding from what @Guy Bedford said on the call. I was double-checking ^_^
yeah, that's exactly the approach - using the Node.js sync but streaming APIs where appropriate. When we have the asyncify work we will be able to call promise-based builtins, but for now perhaps we can see how far we can get while that work is still outstanding.
the other stopgap we have for not having asyncify support in Node.js is the approach we use here to syncify async APIs - https://github.com/bytecodealliance/jco/blob/main/packages/preview2-shim/lib/http/wasi-http.js#L20
the asyncify work will be a little while out so we do just have to work around that for now
is there a reason why IP addresses are typed as tuples?
type ipv4-address = tuple<u8, u8, u8, u8>
type ipv6-address = tuple<u16, u16, u16, u16, u16, u16, u16, u16>
which translate to:
export type Ipv4Address = [number, number, number, number];
export type Ipv6Address = [number, number, number, number, number, number, number, number];
follwing that interface, a localAdress object would look like:
const localAddress = {
tag: sockets.network.IpAddressFamily.ipv4,
val: {
address: [0, 0, 0, 0],
port: 0,
},
};
is that what we are expecting?
Yes in JS that's the representation of a tuple
Great! thank you!
I am trying to write integration tests for wasi-sockets (nodejs impl) inside of ./test/preview2.js
, but it looks like I am missing the obj/
folder. I assumed this folder gets generate after building the projet. I tried to run npm run build
from the root and I am getting these errors. Did I miss something?
@Wassim Chegham make sure you are on the latest Rust toolchain - rustup update
and then with wasm32-unknown-unknown
and wasm32-wasi
targets installed. npm install && npm run build
should then be all you need.
good catch @Guy Bedford I was missing the wasm32-wasi target 🤦🏽 now it's building. Thanks
I've updated https://github.com/bytecodealliance/jco/pull/214 to match the latest WIT updates
Also, @Guy Bedford I've changed the impl to use node.js's internal libuv bindings (tcp_wrap). That was the only way for us to be able to implement the specified WIT ressources.
nice, I guess that will mean we don't support other JS runtimes like Deno or Bun, but we can investigate deno and Bun-specific implementations instead I think then?
But (yes there is a but), I could not figure out what should be the impl of:
accept: func() -> result<tuple<tcp-socket, input-stream, output-stream>, error-code>;
receive-buffer-size: func() -> result<u64, error-code>;
set-receive-buffer-size: func(value: u64) -> result<_, error-code>;
send-buffer-size: func() -> result<u64, error-code>;
set-send-buffer-size: func(value: u64) -> result<_, error-code>;
unicast-hop-limit: func() -> result<u8, error-code>;
set-unicast-hop-limit: func(value: u8) -> result<_, error-code>;
it seems to me like the correct approach
there have been a number of changes to the sockets API
it can be worth keeping an eye on https://github.com/bytecodealliance/wasmtime/pulls?q=is%3Apr+sockets+is%3Aclosed
yes, I went through them and updated the impl
to see the history and upcoming changes as well
those seem like network configurations
Will do
perhaps if we don't have those hooks in Node.js we do just need noops
it's looking really great though, congrats
the resources update is the current big one I'm working on for HTTP
I guess we will need similar updates on sockets
perhaps have a look at my next HTTP PR I'm hoping to finish up today or tomorrow
Thanks!
Guy Bedford said:
it's looking really great though, congrats
It's missing reads and writes thouhg :smile:
right, perhaps that will be related to the streams updates then
In my last commit, I update the impl to remove all the IDs https://github.com/bytecodealliance/jco/pull/214/commits/54ab5cc3fe948f547f2f107cf1cd03f77d388e04
I am planning to start working on upd next :+1:
ah nice to see you figured that out
if you want to verify the interface against the types in https://github.com/bytecodealliance/jco/blob/main/packages/preview2-shim/types/interfaces/wasi-sockets-tcp.d.ts that should roughly match what is the expected shape
Yes. That what I did. I see you updated the type def :+1:
yeah it was a bunch of diffs, thank you for figuring it out there, that wasn't obvious I know
Guy Bedford said:
yeah it was a bunch of diffs, thank you for figuring it out there, that wasn't obvious I know
haha! I am used to reading diffs :grinning:
Wassim Chegham said:
I am planning to start working on upd next :+1:
obviously I meant UDP 🤦🏽
@Wassim Chegham I've been implementing private fields on the other classes, based on what you were doing
thanks for the idea on that one!
@Guy Bedford I applied the latest changes from the main branch to my WIP branch and the FS test is failing because of the new Symbol.dispose
: TypeError: stream[Symbol.dispose] is not a function
. Any idea why is that?
image.png
perhaps try deleting node_modules and reinstalling?
still failing
can I like cargo xtask
clean build?
sounds like it might be a bug only exposed on your branch then
would you like to pair on it?
sure. Let me switch computer. WIll ping you back.
Sent you a DM on Twitter
Adds a new --jco-debug option to jco run which doesn't delete the temporary files (so they can be debugged) and also outputs the trace calls. (https://github.com/bytecodealliance/jco/pull/266)
Thank you so much @Guy Bedford for this! It will save me a lot of headaches. I was currently basically manually compiling each test program and copying it around so I could debug it
./src/jco.js new ./submodules/wasmtime/target/wasm32-wasi/release/preview2_udp_connect.wasm --wasi-command -o __test.wasm
./src/jco.js transpile __test.wasm -o ./
Yay! Made my 1st conformance test pass!!
image.png
Moar conformace tests passing for wasi-socket
image.png
Hi, I just opened an issue in the wasi-socket repo about a question I have, would love if any of you can help https://github.com/WebAssembly/wasi-sockets/issues/82 (cc @Pat Hickey )
@Guy Bedford as discussed yesterday, the wasi-sockets impl for node.js PR is ready for merge: https://github.com/bytecodealliance/jco/pull/214
@Guy Bedford as discussed yesterday, the wasi-sockets impl for node.js PR is ready for merge: https://github.com/bytecodealliance/jco/pull/214
@Guy Bedford The wasi-sockets UDP implem is fully complete (minus a few edge cases - see TODOs in the code) https://github.com/bytecodealliance/jco/pull/306 - I am planning to tackle wasi-sockets TCP next.
yay!!!!
fantastic, will review shortly
Heya @Guy Bedford is there an issue with the recent changes on main? The test runner is now broken. Do we now need to build the tests separatly?
[cause]: 'Unable to read file \x1B[1m./tests/rundir/preview2_udp_bind.component.wasm\x1B[22m'
run cargo xtask generate tests
anyone knows why socket.getRecvbufferSize() would report a different value than the one is set. Eg. in the preview2_udp_sockopts.rs we are setting a buffer size of 0x10000 (66kb) but when reading the value, we get 213kb?
thread 'main' panicked at crates/test-programs/src/bin/preview2_udp_sockopts.rs:61:5:
assertion `left == right` failed
left: 212992
right: 65536
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
@Wassim Chegham perhaps you need to conver the BigInt to a number when setting it
Number(size)
Sure. I tried that but that wasn't the issue :smile:
image.png
While browsing the Internet, I found this affirmation: "In this system, by default, each socket will get a receive buffer with a size of 213 KB. Additionally, the rmem_max value of 213 KB restricts the maximum allowable receive buffer size to 213 KB during socket creation."
https://www.baeldung.com/linux/udp-socket-buffer
so does this mean that setting a value has no effect?!
so I guess it's something that should have an isolated replication
trying now... will report
var s = new dgram.Socket('udp4')
s.bind();
s.setRecvBufferSize(1000);
s.getRecvBufferSize()
definitely seems to work for me
and 65536
also works
perhaps enable the worker-io call logging to verify its definitely being set
or log around the call sites for the set and get
or maybe the replication is more specific and is socket-specific
interesting. Your exact code gave me a EBADF error.
Hummm
image.png
@Guy Bedford can you try this code please?
import { Socket } from "node:dgram";
var s = new Socket('udp4')
s.bind(() => {
console.log('set 1000');
s.setRecvBufferSize(1000);
console.log('get', s.getRecvBufferSize())
});
I get this on WSL:
set 1000
get 2304
so on my machine, I'm getting the same value in get
on that exact case
macOS?
so perhaps this is system specific or something? are you on Windows?
Yes, WSL (ubuntu)
it might be specific to that environment somehow, I'm not sure
ok will add a comment and push so that CI runs
set 1000
get 1000
Heya. So I've submitted a bunch of PRs that are migrating TCP impl to worker thread:
I am tracking the remaining tests to be fixed in https://github.com/bytecodealliance/jco/issues/315. Will work on it over the weekend (once 320 is merged).
So now I am gonna get some Zzzzzzzzz :smile:
amazing!!!! thank you Wassim this is phenomenal progress, and yes please get some rest there!
Just submitted a new PR that makes preview2_tcp_connect
pass! https://github.com/bytecodealliance/jco/pull/321
Last updated: Nov 22 2024 at 16:03 UTC