Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How WebSockets work vs polling/long polling/streaming

websocket.org

Post reply on HN
Print view View original

21–30 of 44 posts

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

#21

Post by rogerbinns »

strictfp wrote: post #15
cagenut wrote: post #11

I get the basic idea, but when I try to flush it out into a full cluster and app design long-poll/web-sockets seems like a bit of a complexity nightmare on the back end. I mean you're taking a highly cachable stateless protocol and turning it into an uncachable one. Then you're taking a shared-nothing application layer and forcing it to do shared-state cache coherence via message passing. And all the way up and down…

Exactly. Ajax in general breaks REST, including bookmarking, caching, navigation and more. All major selling points of HTTP goes out the window. HTTP was created on top of TCP, but with severe restrictions to get the great features which HTTP is well-known for. Now someone re-lauches unrestricted TCP as a feature, when it is in fact much more simplistic and formed the base all along. Usage was purpously off limits du…

> Ajax in general breaks REST

Huh? You are supposed to correctly choose the HTTP verbs and URI path precisely so that HTTP semantics apply.

If you are talking about page state then there are numerous ways of dealing with that - one example is http://diveintohtml5.info/history.html

If your assertion is that developers can write bad code, abuse HTTP semantics, defeat caches, break navigation etc then so what? With the ability to do things right comes the ability to mess them up.

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

#22

Post by halayli »

TazeTSchnitzel wrote: post #20
halayli wrote: post #18

spdy is better designed and supports compression out of the box. I also don't think that a network protocol should be part of HTML5 standard.

The WebSocket protocol isn't part of the HTML5 standard. The API is, but WebSocket's protocol is not defined in HTML5.

The fact that it's mentioned in HTML5 API bothers me.

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

#23

Post by TazeTSchnitzel »

halayli wrote: post #22
TazeTSchnitzel wrote: post #20

Earlier quoted context omitted.

The WebSocket protocol isn't part of the HTML5 standard. The API is, but WebSocket's protocol is not defined in HTML5.

The fact that it's mentioned in HTML5 API bothers me.

Why? They are Web Sockets, and we have AJAX already.

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

#24

Post by EternalFury »

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...

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

#25

Post by mark_story »

rogerbinns wrote: post #21
strictfp wrote: post #15

Earlier quoted context omitted.

Exactly. Ajax in general breaks REST, including bookmarking, caching, navigation and more. All major selling points of HTTP goes out the window. HTTP was created on top of TCP, but with severe restrictions to get the great features which HTTP is well-known for. Now someone re-lauches unrestricted TCP as a feature, when it is in fact much more simplistic and formed the base all along. Usage was purpously off limits du…

> Ajax in general breaks REST Huh? You are supposed to correctly choose the HTTP verbs and URI path precisely so that HTTP semantics apply. If you are talking about page state then there are numerous ways of dealing with that - one example is http://diveintohtml5.info/history.html If your assertion is that developers can write bad code, abuse HTTP semantics, defeat caches, break navigation etc then so what? With the…

I've yet to see an RFC or standard that some developer somewhere didn't totally cock-up. :)

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

#26

Post by halayli »

TazeTSchnitzel wrote: post #23
halayli wrote: post #22

Earlier quoted context omitted.

The fact that it's mentioned in HTML5 API bothers me.

Why? They are Web Sockets, and we have AJAX already.

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.

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

#27

Post by MichaelGG »

strictfp wrote: post #13
ryah wrote: post #12

Earlier quoted context omitted.

"not a good fit" You're speaking of HTTP: the protocol on which a great deal of world's computing infrastructure is being set on top of. The protocol which we are communicating with each other over right now. HTTP on TCP is extremely successful and achieves all it was designed to for and has been extensible to handle much more. There are many basic problems which are abstracted well into stateless request response cy…

I am not dismissing HTTP. The mistake I refered to was to limit TCP usage for www by only allowing the request-response oriented HTTP protocol. HTTP is opinionated and its REST-based architecture was explicitly chosen to disallow partial updates of web pages, thusly crippling TCP. But if one wants to build "thick client" type apps the restrictions of HTTP will weigh you down hard. Allowing for unrestricted TCP usage…

You say HTTP crippled TCP so as to not break-down REST. HTTP 1.0 does not seem to be designed for REST; it doesn't seem that REST was really published until quite a while later. Calling HTTP "REST-based" seems a bit of a stretch.

On top of that, could you give a few examples of what you actually mean? Like what would a partial update be?

TCP seems like a perfect fit for the underlying transport for a request/response model; I don't see how choosing it is some sort of deliberate "crippling". What should they have done? Built a custom request/response protocol on top of IP? Isn't that just crippling IP's flexibility as a layer 3 protocol? I don't understand your objections.

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

#28

Post by Animus7 »

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…

Supply & demand.

Back in the day internet connections were so terrible that it was unbearable to do much more than to download a document and display it. Hence, HTTP and HTML. Arbitrary TCP streams existed but in practice performance and latency were very limiting, so nobody cared that HTTP had no support for streaming.

Eventually the underlying tech matured and the standards followed suit. Slowly. But that's the price of interoperability.

I too find it amusing how these concepts keep getting "rediscovered", but in hindsight it's not surprising.

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

#29

Post by malandrew »

rogerbinns wrote: post #21
strictfp wrote: post #15

Earlier quoted context omitted.

Exactly. Ajax in general breaks REST, including bookmarking, caching, navigation and more. All major selling points of HTTP goes out the window. HTTP was created on top of TCP, but with severe restrictions to get the great features which HTTP is well-known for. Now someone re-lauches unrestricted TCP as a feature, when it is in fact much more simplistic and formed the base all along. Usage was purpously off limits du…

> Ajax in general breaks REST Huh? You are supposed to correctly choose the HTTP verbs and URI path precisely so that HTTP semantics apply. If you are talking about page state then there are numerous ways of dealing with that - one example is http://diveintohtml5.info/history.html If your assertion is that developers can write bad code, abuse HTTP semantics, defeat caches, break navigation etc then so what? With the…

I'm wondering if bookmarking state would have made it into webapps had we not been forced to use HTTP because that is all that was available in the browser for years.

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

#30

Post by ralph »

TazeTSchnitzel wrote: post #19
TazeTSchnitzel wrote: post #3

Earlier quoted context omitted.

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…

Update: I went and bought websocket.us and websockets.us, and put up my own small website about WebSockets. I just want to provide an alternative to Kaazing's site, that has no commercial focus.

As a link, http://websocket.us/
Post reply on HN