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

121–124 of 124 posts

Re: The WebSocket Handbook

#121

Post by ddoolin »

mwcampbell wrote: post #51
ddoolin wrote: post #8

Earlier quoted context omitted.

I think your last paragraph is a good point for using services like the OP. All three of the examples you mentioned are already solved. Granted, you're buying into their paradigm particularly regarding communication model but that's a small price to pay for the upsides. Disclaimer: we've been using Ably for years and their service and reliability has been outstanding, and we have worked closely with their engineers a…

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.

That's an understandable concern you have IMO. As with anything, the solution should fit the problem. Those aren't issues for us but I can empathize with the concern with adding more external services. In our case, we actually tried to implement our own socket "stuff" in one project and ended up switching that to Ably as well just because it was very difficult to both implement and debug over AWS.

Re: The WebSocket Handbook

#122

Post by anderspitman »

twic wrote: post #119
anderspitman wrote: post #96

Earlier quoted context omitted.

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?

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.

Re: The WebSocket Handbook

#123

Post by twic »

anderspitman wrote: post #122
twic wrote: post #119

Earlier quoted context omitted.

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?

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.

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.

Re: The WebSocket Handbook

#124

Post by superasn »

hammersmith wrote: post #41
superasn wrote: post #39

Earlier quoted context omitted.

Hi! I want to create a web app like Google docs where multiple users can collaborate in real time to edit the document together (using a special link like gdocs generate). I want to save the docs in a MySQL db (no firebase) My questions are: 1) Since multiple people are working together how does one manage conflicts, i.e. 2 people sending different edits simultaneously. 2) If one clients gets disconnected (4g) and th…

Have a look at https://m-ld.org/ , its a CRDT implementation that's all Javascript. it could help

Looks very promising. Thanks for sharing!
Post reply on HN