Hacker News Reader

Comment by gfd | Hacker News Reader

I don't know anything about websockets, but isn't it over tcp? Meaning if the client isn't keeping up, their buffer should be full and the server should be blocked from sending more until it drains (unless it's queuing the messages somewhere else?). Or is that not how tcp backpressure works?

View on HN

TCP provides backpressure but depending on it to provide backpressure over the internet will greatly increase latency, in my experience.

In one application I was streaming jpeg frames over a websocket and by the time the server application experienced backpressure there were 10s of seconds of messages buffered between the server and client. So the message rate would eventually settle into a rate the connection could sustain but messages would take 10+ seconds to reach the client.

Perhaps that sounds like a good time to use TCP_CORK, or TCP_NODELAY flags.

Or, perhaps you need to tune the TCP-Window to your application.

> TCP_CORK, or TCP_NODELAY flags

I'm sending large messages, ~150 kibibytes, so much larger than a typical internet packet. So I'm not sure Nagle's algorithm is the problem.

> tune the TCP-Window to your application.

This is a possibility. I already had to increase wmem_max to handle fast udp connections.

I'll try to put together a minimal test case when I get the chance.

One problem is that WebSockets in the browser are 100% asynchronous, ie they don't block on send. So if you have a large amount of data client-side you can easily crash a browser window by sending WS data in a tight loop.

It is, but since you don't control the receive buffer size in the browser, or the TCP window size (or, with many web frameworks, the socket buffer size in the server!), you can't rely on socket buffers giving you timely feedback. By the time the server's send buffer fills, there is already masses of stale data buffered in between you and the client.

In my apps i do indeed detect the socket buffers filling, just as you suggest, but pretty much only as a way of detecting completely wedged clients.

That’s right, but the WebSocket browser API is event driven so the browser HAS TO recv from the socket and dispatch a JS event as soon as data is available.

You’ll get proper back pressure on websockets with synchronous clients that read messages actively.

This is a browser API spec problem more than a protocol problem.

Reply on news.ycombinator.com