Concurrency in the `tcp_echo_server` example

[Heap-Hop]

use wstd::io;
use wstd::iter::AsyncIterator;
use wstd::net::TcpListener;

#[wstd::main]
async fn main() -> io::Result<()> {
    let listener = TcpListener::bind("127.0.0.1:8080").await?;
    println!("Listening on {}", listener.local_addr()?);
    println!("type `nc localhost 8080` to create a TCP client");

    let mut incoming = listener.incoming();
    while let Some(stream) = incoming.next().await {
        let stream = stream?;
        println!("Accepted from: {}", stream.peer_addr()?);
        io::copy(&stream, &stream).await?;
    }
    Ok(())
}

Currently, the main example in this project is non-concurrent.
io::copy(&stream, &stream).await blocks new incoming streams.
It doesn’t make much sense to use an async runtime if streams are processed sequentially.

It would be great to see this example become concurrent.

Related:
#17
yoshuawuyts/wasm-http-tools#7

[Heap-Hop]

By the way, it seems that each new piece of data from InputStream triggers Pollable(from socket.subscribe()) twice. The first call works as expected, but the second one reads 0 data, which breaks the loop in io::copy(&stream, &stream).

see:
https://github.com/Heap-Hop/wstd/blob/2f7c736c0dee60216e89047c7bf2aca6acb18535/tests/test-programs.rs#L122-L140
https://github.com/Heap-Hop/wstd/actions/runs/11973369194/job/33382147774#step:5:273

This also occurs in a standalone Wasmtime environment. Is this behavior expected?

[pchickey]

In https://github.com/Heap-Hop/wstd/blob/2f7c736c0dee60216e89047c7bf2aca6acb18535/tests/test-programs.rs#L122-L140 you're trying to read_to_end on a connection that already ended, so thats expected to no longer provide more output.

I agree we can make the example better! This crate is rapidly evolving right now but I will try to revisit that soon. I also want to rewrite the host side of the test to just use tokio instead of being kinda contorted to just use std. If you want to send a PR to fix any of these things, feel free.

[Heap-Hop]

Thanks for your reply!
I’m trying out futures_concurrency::future::FutureGroup, and would love to contribute as soon as I better understand your design philosophy (#17).

Regarding TcpStream, I'm sorry I didn't realize it was using read_to_end. I had only modified the original code.

One more question: who is responsible for closing the connection? Is read_to_end expected to wait indefinitely?

I’ve updated my testing to use a read, and you can observe the broken connection.
https://github.com/Heap-Hop/wstd/blob/cc3b34795842d8545d30be4a1e92bd1221a05fe0/tests/test-programs.rs#L134
https://github.com/Heap-Hop/wstd/actions/runs/11982701484/job/33411136111#step:5:272

[Heap-Hop]

Or you can run the tcp_echo_server example and connect to it using nc localhost 8080. Once you send any data, the connection will break immediately.

[pchickey]

I'll have to dive into this further, I already know of at least the buffering bug in TCP streams #23 and its likely more will shake out when we change the example to serve many connections concurrently.

[Heap-Hop]

#32
Here's my version of a non-blocking tcp echo server example.