reply on: You might not need WebSockets \ stacker news ~tech

pull down to refresh

0 sats \ 8 replies \ @ek 12 Apr \ parent \ on: You might not need WebSockets tech

periodically send keepalive messages to avoid the server dropping the stream if it stays idle too much

Can’t you just retry with HTTP if the stream is dropped? And you don’t have to do that with websockets?

implement message parsing

You don’t have to parse the app-specific messages you send over websockets?

implement multiplexing

Is this not built into HTTP/2?

100 sats \ 5 replies \ @rblb 12 Apr

Can’t you just retry with HTTP if the stream is dropped? And you don’t have to do that with websockets?

No, you don't have to do that with websockets, because you rely on the tcp stack to do that. HTTP/2 connections are also tcp, of course, but they have an idle timeout, after which the socket is forcefully closed. You can reopen the http stream, sure, but you will be dealing with a dirty close.

You don’t have to parse the app-specific messages you send over websockets?

I am not talking about parsing the content of the message, but extracting the message from the stream. Websocket are message based, if you use a raw http stream you'll have to figure out where the message starts and where it ends.

Is this not built into HTTP/2?

Not if you abuse the protocol like that, because your application will pipe all the data through a single stream and wait for responses, you'll have implement a queue for writers, and a callback mechanism of some sort, if you want it to be efficient.

0 sats \ 4 replies \ @ek 12 Apr

If you could create YouTube, Netflix, Amazon Prime etc. from scratch, would you use websockets instead of HTTP streaming?

0 sats \ 3 replies \ @rblb 12 Apr

These are all examples of unidirectional data stream with little to no idle time. That's what http streams are for and not what the article is talking about.

0 sats \ 2 replies \ @ek 12 Apr

So when you said

to make this work in real life

You didn’t mean the example of using HTTP streams instead of websockets that came at the end?

So what’s the alternative?

We touched on it very briefly in the previous sections, but if we can abstract away the transmitting side of the socket and only be left with a one-way stream of data on the receiving side, we can use a much simpler communication pattern.

What did you refer to with "this" then?

The post title is "You might not need websockets." When you say "to make this work in real life", you’re either referring to the example in the article or dismissing every case in which you want to stream something in some way that is not using websockets.

What do you think the article was talking about?

0 sats \ 1 reply \ @rblb 12 Apr

Ok.. i'll try once again:

This entire concept will not work reliably because servers, intermediaries and clients will drop the connection if there is no data transmission for some time. That's what i mean with "not working in real life". You'll have to send keepalive packets and do all the stuff that tcp is already doing for you.

HTTP streaming is to stream data you already have (eg. streaming a video from netflix or the feed from twitch), they are not designed for what is shown in the example, for the things i said earlier.

If you don't believe me or don't get it, I think you should look into why websockets were created in the first place.

0 sats \ 0 replies \ @ek 12 Apr

If you don't believe me or don't get it, I think you should look into why websockets were created in the first place.

Thank you, will do

reply on another page

0 sats \ 1 reply \ @ek 12 Apr

Sounds to me like you’re mentioning reasons why websockets are shitty but instead of saying websockets are shitty, you say any other method needs to be just as shitty, else it’s even shittier.

0 sats \ 0 replies \ @rblb 12 Apr

No, i am saying that implementing an half baked tcp socket on top of an abused http request doesn't make sense when you have websockets that are a proper wrapper around lower level tcp.