[twic]

Nice work on omnistreams!

The WebSocketStream API is a small improvement, because it can leave backed-up messages in the socket buffer, but it still means you're depending on socket buffers for backpressure, which i think is not enough. There's still no way to actually set the receive socket buffer size in the browser, is there?

[anderspitman]

I believe socket backpressure would have worked for my use case. Curious why you think it wouldn't be enough?

As far as I know there's no way to set buffers. IIRC there's a buffer value you can check which is what I tried to use first but don't think that got me very far. Seems like Chrome and Firefox handled it differently or something.

[twic]

As far as i know, browsers do not set a receive buffer size for websockets, so if a client is not reading from the websocket fast enough, the kernel will expand the buffer until it reaches its maximum size, which on my machine is 6 MB. Say you are writing 1 kB/sec of data to this websocket. It will take ~100 seconds to fill.

That means that you won't even know that a client is stuck for a minute and a half (plus however long it takes to fill your send buffer!), and even if you then throttle back, the client has a minute and a half of high-rate data to work through before it catches up. If you throttle up again once you see that the buffer is clearing, and the client gets overloaded again, you will keep hovering around that buffer full state, and the client will keep reading significantly stale data.

To get a useful real-time signal from socket buffers, you need them to be really small. But to get nice smooth transfers of bulk data, you need them to be big, so that is what is the default.