Direct transfers on Windows blocks after a couple of MBs transferred

[kernelPanic0x]

Has someone tried sending large files via localhost on the same computer? When I do that, it just sends the first 100-200MB and then stops like a deadlock. Is this a backpressure problem?

I don't get an error message but it just stops transferring. It seems to be only a problem on local connections on the same machine, maybe because of the ultra-low latency and fast speed that you normally don't have via real networks. Can someone confirm this?

I am currently using windows. Maybe this has something to do with this issue.

[felinira]

I don't experience the same issue. Maybe try opening in lldb and see where it hangs.

Not using windows though, so no idea if that's related in any way.

[kernelPanic0x]

I have tested on linux and as you said there is no problem. I am running Windows 10 21H2. Seems like a windows issue to me or with my specific hardware 🤷‍♂ . I also encountered this problem while sending normally to another machine. Very strange 👀 ...

[felinira]

If a windows user wants to try to debug this, help would be welcome.

[Cyanic]

So I'm seeing the same thing... err maybe different, but same result.

My setup is two Windows 11 Enterprise machines on different networks connected via Wireguard.

I get around 300 MB quickly and then it dies. So same results same OS but different network topology.

I got onto wormhole-rs via regular wormhole. Using the python version same test it works but is slow, only getting around 4MB/s but it's very stable and have transferred 17GB at a time.

Not sure what the issue is but happy to help debug.

[felinira]

Maybe try opening in lldb and see where it hangs.

This idea still applies as a starting point. But honestly it's really difficult to debug such issues. So good luck!

[Cyanic]

lldb is only on Linux no? This is between two Windows machines. With Wormhole it would say if it was connected locally or via the relay but with Wormhole-rs I don't see anything like that, even with -v enabled.

I have some Ubuntu VMs I could try spinning up on the two networks I guess. That should perhaps isolate it to the OS and not the network.

[kernelPanic0x]

Could it be a problem with async-std backend on windows? Is tokio maybe more stable with buffer management under high load on windows?

[Cyanic]

If anyone needs me to test I'd be happy to do whatever testing is needed.

[kernelPanic0x]

I think we need to ditch async-std and switch to tokio because it has been discontinued and does not use the windows kernel directly like tokio does.

Sorry for the slop table 😂 but this is what i found:

Why Tokio is better suited for Windows High-Throughput Transfers

Feature	Tokio	async-std
Low-level Driver	mio: Highly mature; provides a robust "readiness" shim over Windows IOCP.	polling: A lighter abstraction; historically more prone to edge-case stalls on Windows.
I/O Strategy	Direct IOCP Integration: Optimized over 8+ years to handle the Windows Completion model.	Generic Abstraction: Aims for simplicity across OSs, which can lead to "Lost Wakers" under high Windows I/O load.
Windows Stability	Handles high-speed backpressure (Localhost/LAN) by correctly re-arming wakers.	Known issues where the executor "misses" a completion signal when the TCP window fills up.
Maintenance	Active: The industry standard for Rust async, with frequent updates for Windows edge cases.	Stagnant: Very few commits in recent years; deep architectural bugs on Windows often go unfixed.
Performance	Multi-threaded scheduler is highly optimized for high-throughput network tasks.	Uses a simpler executor that can suffer from thread starvation during heavy disk/network contention.

---

[kernelPanic0x]

Maybe tokio-utils can ease the transition a bit? 👀