WebSocket back-pressure

[tomaka]

JavaScript, in its splendour, doesn't provide any way whatsoever to back-pressure WebSockets.
At the moment the Smoldot Wasm node will simply keep buffering data coming from the socket, and process this data asynchronously. If it is too slow to process messages, it will simply panic on OOM.

I suppose that JS environments will actually back-pressure WebSockets if they're not given the chance to run their internal events loop. In other words, it would work if the connection_message function doesn't return before having fully processed the incoming message. This, however, is most likely not possible.

Three possibilities to fix this:

• Add a maximum buffer size, and kill the connection altogether if this buffer size is exceeded. Clearly not a robust solution.
• Design some sort of the metaprotocol where the client gives the authorization to the server to send more data.
• Switch to WebRTC. I don't know about the back-pressure situation regarding WebRTC, but considering that WebSockets servers are assumed to be trusted by the client while WebRTC peers are not means that the situation is probably better.

[melekes]

Design some sort of the metaprotocol where the client gives the authorization to the server to send more data.

I feel like I've seen this before 😃 aka in tcp

[melekes]

the data channel in WebRTC is based on SCTP which has build-in flow control (FC). Sctp has a max message size setting. Other than that, each data channel has a buffered_amount() fn, which returns a number of bytes in a buffer. We'll probably need to cap the buffer and return an error to the caller if buffer is full.

UPD: just checked. webrtc-rs DataChannel has a write queue, which seems to be unbounded. So what I wrote above stands.

[tomaka]

In this context we're interacting with the WebRTC API of the browser, not with webrtc-rs, although of course the problem is also relevant for webrtc-rs.

One thing that's missing from smoldot is a change to the JS <-> Rust FFI that lets you do this back-pressure.

[tomaka]

cc w3c/webrtc-nv-use-cases#44