How WebSockets work vs polling/long polling/streaming • Hacker News Board

Re: How WebSockets work vs polling/long polling/streaming

#41

Post by halayli » Mon, May 28, 2012, 5:03 PM UTC

TazeTSchnitzel wrote: post #31

halayli wrote: post #26

Earlier quoted context omitted.

Ajax is merely a client JS interface to HTTP. A protocol that already exist. It's not a protocol being imposed on web servers. When you want to impose a new protocol on web servers and browsers, it better not be to solve push notifications only. And that's what SPDY did.

WebSocket isn't just to solve push notifications. It's also for realtime communication, for example chat or multiplayer games. We do have server-sent updates if you just want push notifications.

yes, without compression. Everything you said is covered in SPDY. But SPDY takes a step further and improves the current state of HTTP as well to better transfer documents.

Re: How WebSockets work vs polling/long polling/streaming

#42

Post by lenkite » Mon, May 28, 2012, 5:33 PM UTC

"..., it cannot deliver raw binary data to JavaScript, because JavaScript does not support a byte type" Incorrect. JS most definitely supports binary data using byte arrays with Uint8Array, etc or using canvas data binary

Re: How WebSockets work vs polling/long polling/streaming

#43

Post by gcr » Mon, May 28, 2012, 6:13 PM UTC

EternalFury wrote: post #24

strictfp wrote: post #9

I find it amusing that TCP was designed as and still is a full-duplex protocol for long-lived connections (streams). Then someone decides to use it in HTTP (1.0) for short-lived, half-duplex, message-oriented communication. Not surprisingly, it is not a good fit. Fast-forward a couple of years and everybody is busy de-crippling TCP in HTTP with various hacks trying to delay the HTTP request-response cycle, thus uncov…

Wait a little longer and, if we are very lucky, multicast will be "re-discovered" as well. That way, instead of having servers shove data down many sockets to many clients, they will write their payload down 1 multicast socket to all interested clients, with said payload crossing the network as little and as far as necessary but not more. So goes the wheel of progress...

Sounds like ZeroMQ's "rediscovered" multicast as you describe.

Re: How WebSockets work vs polling/long polling/streaming

#44

Post by peterlubbers » Tue, Jun 05, 2012, 9:10 PM UTC

Just to let you all know that this is an old article (agree that a publish date would have helped there). Frank and I published this article originally in late 2009 or early 2010. That was around the time that WebSocket first landed in Chrome and there have been a lot of updates to the protocol since then. For example, WS was text only, and I don't think socket.io existed yet ;-)