Web socket in Rust

[afsalthaj]

Fixes #3053

Rust Agent Websocket

// In test-components/host-api-tests/components-rust/golem-it-host-api-tests/src/websocket.rs
use golem_rust::{agent_definition, agent_implementation};
use golem_rust::{WebsocketConnection, WebsocketMessage};

#[agent_definition]
pub trait WebsocketTest {
    fn new(name: String) -> Self;
    fn echo(&self, url: String, msg: String) -> String;
}

pub struct WebsocketTestImpl { _name: String }

#[agent_implementation]
impl WebsocketTest for WebsocketTestImpl {
    fn new(name: String) -> Self { Self { _name: name } }

    fn echo(&self, url: String, msg: String) -> String {
        let ws = WebsocketConnection::connect(&url, None).expect("connect");
        ws.send(&WebsocketMessage::Text(msg)).expect("send");
        match ws.receive().expect("receive") {
            Message::Text(t) => t,
            Message::Binary(b) => format!("{} bytes", b.len()),
        }
    }
}

[vigoo]

Looks good so far. Let's have a per-executor semaphor to constraint the number of parallel websocket connections (we already have it for regular http connections). This way we protect the executor from overloading with ws sockets. (Let the connect rather wait than the whole server overloading or running out of sockets)

[vigoo]

Why are these not worker-executor tests?

[afsalthaj]

I think I tried to place these tests in ehre, and was failing with registry service errors.. I can try again

[vigoo]

It would be a better place, as we can much quicker and easier iterate on it and this is an executor feature (not depending on any other service)

[mschuwalow]

This has no durability at all, right? Would it make sense to only allow using websocket connections within a persist-nothing region? Otherwise we are going to reexecute (the potentially side-effecting) connections during replay

[vigoo]

This has no durability at all, right? Would it make sense to only allow using websocket connections within a persist-nothing region? Otherwise we are going to reexecute (the potentially side-effecting) connections during replay

It will have durability, I asked for adding it in two new phases on top of this.

[vigoo]

If this is no-op, we cannot to async websocket communication in our agents.
A minimal version would be something like:

• a separate blocking_receive (the current receive) and non-blocking receive (returns None if there is no current message to receive)
• this ready() function async-blocks until we know that the next call to receive will return Some

With that it's possible to mix async ws reads with other operations in the agent. (And send is still always blocking).

Depending on how send is implemented it may make sense to make an async send too (if there is backpressure by some limited output queue). In that case we may need two different subscribes.

The most advanced and idiomatic version would probably be if a connected websocket would materialize in a wasi InputStream and OutputStream (with properly implemented read() for each - like wasi-http input/output streams do). I don't remember if this is possible without touching the wasmtime fork though.

[vigoo]

Let's write a "real" async test as well, which is an async agent method and uses wstd to convert the pollable to a future, and does real bidiretional messaging (multiple sends, multiple receives, receive being async through wstd)

[afsalthaj]

done

[vigoo]

Small note (only fix if you do other changes anyway): the only reason we do explicit drop of the executor and stop of the servers in the end of the test is to put the assertions after them. this way logs coming from stopping the executor are always before the actual assertion failure

[vigoo]

you just told me a few hours ago to do a single subscribe outside the loop :)

[afsalthaj]

:D hehe yes. I can move that out