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

91–100 of 124 posts

Re: The WebSocket Handbook

#91

Post by dmm »

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?

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.

Re: The WebSocket Handbook

#92

Post by klabb3 »

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…

There should be a law for message passing systems, which says that everyone will eventually want ordered delivery, multiplexing (with priorities), exactly-once semantics, acknowledgements and backpressure. (Maybe more?)

I'm pretty convinced all these popular features could be layered in a reasonable way that could be implemented in most messaging systems, and have standardized semantics and conventions. It seems like every time, we're reinventing the wheel, and half the time people talk over one-another because we're using inexact language.

Basically, what I want is a "message passing a la carte" paper.

Re: The WebSocket Handbook

#93

Post by cookiengineer »

A couple months ago I posted the "Implementer's guide to WebSockets" that I wrote, but it seemingly got shadowbanned. [1]

I wrote the guide with example code for people wanting to know how to implement the complete WS13 protocol from scratch, so you can try it out, fiddle around and modify it to your needs.

The guide is more in-depth and assumes that the reader is willing to read the RFC when they're stuck :)

[1] https://cookie.engineer/weblog/articles/implementers-guide-t...

Re: The WebSocket Handbook

#94

Post by twic »

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?

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.

Re: The WebSocket Handbook

#95

Post by Groxx »

klabb3 wrote: post #92
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…

There should be a law for message passing systems, which says that everyone will eventually want ordered delivery, multiplexing (with priorities), exactly-once semantics, acknowledgements and backpressure. (Maybe more?) I'm pretty convinced all these popular features could be layered in a reasonable way that could be implemented in most messaging systems, and have standardized semantics and conventions. It seems like…

"Every sufficiently-complex system eventually includes a badly-implemented email / lisp / kafka (/zmq/etc)"

Something like a combination of Greenspun's Tenth Rule[1] and Zawinski's Law[2]. Plus whatever would include your queueing system of choice.

Though honestly I've seen more bad queues than emails or lisps. By an order of magnitude or two.

[1]: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule [2]: https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski's_Law

Re: The WebSocket Handbook

#96

Post by anderspitman »

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 the end of the day I think RSocket is probably the way to go for most people, though the simplicity of omnistreams is still appealing to me.

EDIT: I just learned about WebSocketStreams[2] from another comment[3] and sounds like they may solve the backpressure issue natively.

[0]: https://github.com/omnistreams/omnistreams-spec

[1]: https://iobio.io/2019/06/12/introducing-fibridge/

[2]: https://web.dev/websocketstream/

[3]: https://news.ycombinator.com/item?id=29894938

Re: The WebSocket Handbook

#98

Post by anderspitman »

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?

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.

Re: The WebSocket Handbook

#99

Post by chalas_r »

crummy wrote: post #78
chalas_r wrote: post #64

Mercure is an alternative to WebSocket that is especially useful for REST/GraphQL APIs. It's a protocol that builds on HTTP and Server-Sent Events thus is supported out of the box by browsers, mobile apps and IoT clients, and it doesn't suffer from most WebSocket limitations (e.g. header/cookie based authorization works): https://mercure.rocks

> it doesn't suffer from most WebSocket limitations (e.g. header/cookie based authorization works) Don't WS connections send headers? What's the limitation here?

Actually neither the WebSocket nor the SSE browser APIs allow to send custom headers (see https://stackoverflow.com/q/4361173/4363634, https://stackoverflow.com/q/36201347/4363634). Point is that the Mercure protocol specifies the authorization part deeply so it's handled out of the box. With WebSocket you are on your own.

Re: The WebSocket Handbook

#100

Post by mobilio »

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.

YNWA!
Post reply on HN