Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The WebSocket Handbook

ably.com

Post reply on HN
Print view View original

111–120 of 124 posts

Re: The WebSocket Handbook

#111

Post by dragontamer »

dmm wrote: post #91
gfd wrote: post #89

Earlier quoted context omitted.

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?

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…

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.

Re: The WebSocket Handbook

#112

Post by drunkenmagician »

matt_oriordan wrote: post #52
mwcampbell wrote: post #51

Earlier quoted context omitted.

I'm generally reluctant to add dependencies on third-party services such as Ably in the core application, because that would add another barrier to providing an on-prem deployment option, or even allowing a customer to deploy on their own AWS infrastructure instead of ours. I'm actually contemplating this decision right now for a new product.

I am surprised to hear about on-prem deploys when the direction of travel is towards serverless/cloud solutions that don't require orchestration. Out of interest, why is on-prem so important for your use case? Separately, I'd be interested in how you'd view that decision if there was a less scalable but mostly fully functioning open source version of the third-party service you could deploy if you needed to? Matt, co…

Where I'm based (in Asia) on-prem is definitely a need for some sectors. Banks and financial institutions, healthcare, government etc. They may not need it for all solutions, but they sure want to know they can have it if needed. Its the very reason we (SaaS company) make sure we don't rely on any cloud PaaS services for our product.

Re: The WebSocket Handbook

#113

Post by 62951413 »

anderspitman wrote: post #103
gfd wrote: post #90

Does anyone know when to choose http2 vs websockets?

I'm assuming you mean HTTP/2 with Server-Sent Events, since raw HTTP/2 frames aren't exposed in the browser? My answer would be use HTTP/2 + SSE whenever you can get away with it. The primary limitation of SSE in this case is you can't natively send binary data (you would have to base64 encode it or something). If you're just using JSON or another text format anyway this isn't an issue.

Wouldn't HTTP2 imply https://github.com/grpc/grpc-web instead?

Re: The WebSocket Handbook

#114

Post by zamadatix »

twic wrote: post #85

I use websockets quite a lot, for real-time dashboard kind of purposes. The one thing i really wish websockets had is some kind of application-level acknowledgement or backpressure. At the server end, you're blasting out messages to the client, but you have no idea if it is keeping up with them. Most of the time, it will be, but if there is a sudden spike of activity, suddenly all your dashboards are going wild, and…

If it's streaming data like dashboard statistics then going forward the new WebTransport API might be a much better base: https://github.com/w3c/webtransport/blob/main/explainer.md At this instant it's hot off the assembly line though having just shipped in Chrome 97, Firefox is still working on it.

Re: The WebSocket Handbook

#115

Post by rezonant »

zamadatix wrote: post #114
twic wrote: post #85

I use websockets quite a lot, for real-time dashboard kind of purposes. The one thing i really wish websockets had is some kind of application-level acknowledgement or backpressure. At the server end, you're blasting out messages to the client, but you have no idea if it is keeping up with them. Most of the time, it will be, but if there is a sudden spike of activity, suddenly all your dashboards are going wild, and…

If it's streaming data like dashboard statistics then going forward the new WebTransport API might be a much better base: https://github.com/w3c/webtransport/blob/main/explainer.md At this instant it's hot off the assembly line though having just shipped in Chrome 97, Firefox is still working on it.

Oh wow this is going to be useful

Re: The WebSocket Handbook

#116

Post by dimgl »

friendlydog wrote: post #3
AlexTDiaconu wrote: post #2

Hi HN! I'm Alex, and I've been researching and writing about WebSockets for a while now. I'm the author of the recently released WebSocket Handbook. AMA about the WebSocket tech, the realtime web, Ably or anything related to Liverpool FC.

What is the right way to handle authentication over web sockets?

In a Golang app I'm writing now, I have middleware that authorizes requests. Authenticated requests have a header with a JWT token. I have an endpoint for websockets where if an authenticated request comes in (the handshake) that request is then upgraded to a Websocket connection. This is the cleanest authentication implementation I've ever used thus far, and I wasn't able to achieve the same thing in Node when I was using socket.io.

I'm sure there are repercussions to this on the client-side, but I haven't gotten to that point yet. I'm still writing the server and testing it using automated integration tests.

Re: The WebSocket Handbook

#117

Post by anderspitman »

62951413 wrote: post #113
anderspitman wrote: post #103

Earlier quoted context omitted.

I'm assuming you mean HTTP/2 with Server-Sent Events, since raw HTTP/2 frames aren't exposed in the browser? My answer would be use HTTP/2 + SSE whenever you can get away with it. The primary limitation of SSE in this case is you can't natively send binary data (you would have to base64 encode it or something). If you're just using JSON or another text format anyway this isn't an issue.

Wouldn't HTTP2 imply https://github.com/grpc/grpc-web instead?

Maybe. I've never seriously considered grpc-web since it requires a special proxy (Envoy) to work. Seems like too many layers of complexity at that point.

Re: The WebSocket Handbook

#118

Post by thibauts »

gfd wrote: post #89
twic wrote: post #85

I use websockets quite a lot, for real-time dashboard kind of purposes. The one thing i really wish websockets had is some kind of application-level acknowledgement or backpressure. At the server end, you're blasting out messages to the client, but you have no idea if it is keeping up with them. Most of the time, it will be, but if there is a sudden spike of activity, suddenly all your dashboards are going wild, and…

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?

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.

Re: The WebSocket Handbook

#119

Post by twic »

anderspitman wrote: post #96
twic wrote: post #85

I use websockets quite a lot, for real-time dashboard kind of purposes. The one thing i really wish websockets had is some kind of application-level acknowledgement or backpressure. At the server end, you're blasting out messages to the client, but you have no idea if it is keeping up with them. Most of the time, it will be, but if there is a sudden spike of activity, suddenly all your dashboards are going wild, and…

I built omnistreams[0] primarily because of the lack of backpressure in browser WebSockets (lots of background information and references in that README). It's what fibridge[1] is built on. We've been using it in production for over 2 years, but I never ended up trying to push omnistreams as a thing. I believe the Rust implementation is actually behind the spec a bit, and the spec itself probably needs some work. At…

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?

Re: The WebSocket Handbook

#120

Post by dmm »

dragontamer wrote: post #111
dmm wrote: post #91

Earlier quoted context omitted.

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…

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.

Post reply on HN