Can I have flow control on my websockets?

I doubt what you are asking for is possible. There is no interface for that functionality in the WebSocket API spec. What the spec does outline, however, is a requirement that the underlying socket connection be managed in the background outside of the script that is using the WebSocket, so that the script is not blocked by WebSocket actions. When the socket receives inbound data, it wraps the data inside of a message and queues it for the WebSocket script to process. There is nothing to block the socket from reading more data while messages remain in the queue waiting for the script to process them.

The only real flow control you can implement in a WebSocket is an explicit one. When a message arrives, send back a message to acknowledge it. Make the server wait to receive that ack before sending its next message.

It’s now possible to have streams within WebSocket. Chrome 78 will ship with a new WebSocketStream API, which supports backpressure.

Here’s a quote from Chrome Platform Status:

The WebSocket API provides a JavaScript interface to the RFC6455 WebSocket protocol. While it has served well, it is awkward from an ergonomics perspective and is missing the important feature of backpressure. The intent of the WebSocketStream API is to resolve these deficiencies by integrating streams with the WebSocket API.

Currently applying backpressure to received messages is not possible with the WebSocket API. When messages arrive faster than the page can handle them, the render process will either fill up memory buffering those messages, become unresponsive due to 100% CPU usage, or both.

Applying backpressure to sent messages is possible but involves polling the bufferedAmount property which is inefficient and unergonomic.

Unfortunately this is a Chrome-only API and there is no web standard at time of writing.

For further info see:

• Issue 983030: Implement WebSocketStream