How WebSockets work vs polling/long polling/streaming
1–10 of 44 posts
Re: How WebSockets work vs polling/long polling/streaming
#2Looks like an advertorial. No mention of socket.io and praise for a commercial solution that I didn't know after almost two years working with websockets.
Re: How WebSockets work vs polling/long polling/streaming
#3Looks like an advertorial. No mention of socket.io and praise for a commercial solution that I didn't know after almost two years working with websockets.
Yup. It is an advertorial. Kaazing like promoting their own "WebSocket Gateway", and they're in a great position to, owning websocket.org
By the way, at the moment I'm using Python's Twisted with a simple wrapper called txWS: https://github.com/MostAwesomeDude/txWS
I'm not a big fan of socket.IO, seems too complex for my needs. I was quite happy to discover txWS, it's literally one more function call and you can just write ordinary Twisted code with no changes, which is a relief.
Edit: I'm tempted to purchase websockets.co...
Re: How WebSockets work vs polling/long polling/streaming
#4Looks like an advertorial. No mention of socket.io and praise for a commercial solution that I didn't know after almost two years working with websockets.
It is in the last paragraph. I thought the 90% of the article prior to that was a pretty good neutral overview of websockets vs prior 2-way alternatives.
Re: How WebSockets work vs polling/long polling/streaming
#5Looks like an advertorial. No mention of socket.io and praise for a commercial solution that I didn't know after almost two years working with websockets.
While definitely having an agenda, I still found it a useful high-level guide.
Re: How WebSockets work vs polling/long polling/streaming
#6Looks like an advertorial. No mention of socket.io and praise for a commercial solution that I didn't know after almost two years working with websockets.
While definitely having an agenda, I still found it a useful high-level guide.
True but some of the data looks to be "dated". According to Wikipedia, Safari, Chrome FF, and IE10 have WS support.
Re: How WebSockets work vs polling/long polling/streaming
#7Earlier quoted context omitted.
While definitely having an agenda, I still found it a useful high-level guide.
True but some of the data looks to be "dated". According to Wikipedia, Safari, Chrome FF, and IE10 have WS support.
Man I hate these undated Internet articles. Publishers use it to sneakily squeeze out a few extra page views from stale content. Hate it when I fall for that.
Besides support in recent browsers, anything else inaccurate in it?
Re: How WebSockets work vs polling/long polling/streaming
#8Their claim that "HTML5 Web Sockets can provide a 500:1 or—depending on the size of the HTTP headers—even a 1000:1 reduction" is also wrong as they dont account for TCP / IP Frame overhead. Sure it still is around 50:1, and sockets are awesome. But if you present numbers, please dont present misleading numbers.
Re: How WebSockets work vs polling/long polling/streaming
#9I 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 uncovering the streams in the underused underlying protocol. First now, many years later, the mistake is properly corrected and TCP on the www is vindicated through websockets. Funny world.
Re: How WebSockets work vs polling/long polling/streaming
#10He seems to play up the problems with comet-style communication quite a bit. Most of his objections, and it seems the entirety of his 'showdown' is based on using the slowest comet implementations, which do repeated HTTP requests, rather than the obvious and, as far as I know, most commonly used streaming approach. Honestly, I see little difference between streaming comet communication and web sockets in terms of performance/overhead.
And why does the "Complexity of comet applications" diagram show "RIA client app" (does this not have to be built when using web sockets?), "Silverlight or Flash plugin" (as if these are necessary for comet), and some convoluted server-side architecture that has nothing to do with the client-server protocol? Again it seems like trying to play up the deficiencies of comet-type apps in a kind of disingenious way.
Web sockets seem to be a great step forward in almost every way (cross-platform support currently missing) so why hype them with imagined performance wins from unrealistic comparisons with other solutions.