How reliable is websocket transportation to the browser?

As reliable as any other TCP connection. What are you trying to do?

I'm not really clear on how a web sites gets access to TCP transportation, but I'm assuming it's via some kind of sandbox that the browser contains.

I'm trying to decide if streaming to the browser is even a good idea, or if I should stick to polling things.

I have this application that renders a 3d environment and the entities' position within this environment is constantly updating.

So say I have for example 3000 entities moving around and they each have an x, y, z coordinate and a few bytes of metadata on them.

Web sockets should have a lower overhead as doing http polling will have overhead of headers, cookies etc.

I need something like retry logic and in band keep-alives right?

Because I won't be able to access TCP keepalive or similar things inside the browser right?

Or does the browser do that for me?

I barely know what I don't know here 😄

Haha

Yes you need your own retry logic, and keep alive. Honestly I’d use a library that handles those for me.

Yeah I'm looking at something like that. We've tried grpc-web but the streaming logic was leaking all over the place and you barely need it for the backend where you can use HTTP2.

Maybe something like STOMP is a good enough protocol.

An alternative worth considering is using SSE which is push only (not bidirectional) and handles retry and keep alive. But it’s a more obscure tech, albeit simpler.

Yeah I've actually looked into that quite a bit and even built a grpc http2 stream -> sse http1.1 proxy thingamajig, but the handing of retries and such was a bit off

I still needed in-band keepalives to make sure the browser really understood if it had lost the connection in all cases.

Yeah then websockets is probably the browser tech to use. You can have your own ACK logic etc.

It would be interesting / terrifying to understand the differences between browsers and socket handling as well but I am frankly disgusted by the prospect of learning that stuff and then having the Chrome team pull my rug out from under me 😄

Http2 is unrelated, no? I don’t think it handles your use case.

Yeah it's just that grpc is built on top of http2

Ah - I don’t know a thing about grpc

Sorry it was a bit out of context there - it's an argument against streaming grpc between backend services since due to their HTTP2 nature the request response is pretty efficent anyway

And the streaming abstraction is not great for grpc

The only downside about websockets that I’ve seen in the wild is some corporate frameworks silently blocking them.

Ah yeah interesting

So libraries like http://socket.IO or sente give you an API that will fall back to long polling.

https://github.com/ptaoussanis/sente

That's neat yeah I've heard about sente

The gentlemen building the frontend in question have chosen angular to build their application (yes I'm interested in another job...) so I'll have a look at what they can use from there easily 😃

http://Socket.IO is the leading js framework i think.

Thanks for the discussion @orestis I really appreciate having someone to geek out about over web protocols at 10:44 in the morning on a saturday 😄 Much love and have a great weekend

Even new jira is absolutely infuriating.