7 ms·

streaming

116 points by SkyMarshal 14y ago

davidpardo 14y ago
Looks 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.
- TazeTSchnitzel 14y ago
  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 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...
  - TazeTSchnitzel 14y ago
    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.
    - ralph 14y ago
      As a link, http://websocket.us/ http://websocket.us/
  - majke 14y ago
    Shameless plug: SockJS is non-complex alternative to Socket.io, websockets polyfill.
    - TazeTSchnitzel 14y ago
      Added to WebSocket.us, thanks!
- SkyMarshal 14y ago
  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.
- seldo 14y ago
  While definitely having an agenda, I still found it a useful high-level guide.
  - lbotos 14y ago
    True but some of the data looks to be "dated". According to Wikipedia, Safari, Chrome FF, and IE10 have WS support.
    - SkyMarshal 14y ago
      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?
Liongadev 14y ago
Their 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.
strictfp 14y ago
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 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.
- ryah 14y ago
  "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 cycles: file serving, RPC. There was no "mistake" - it was not a bad fit. There are only expanding use-cases involving existing software infrastructure - for which websockets is solution. That's not to say that HTTP is perfect... It could be better in many ways - but it's ridiculous to write off its success and call it a mistake.
  - strictfp 14y ago
    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 makes a lot more sense in that case, and is exactly what WebSockets delivers. One can argue that we were better off with the pure REST web before XmlHttpRequest, in fact I am inclined to agree there, but the crippling of TCP was bound to be cracked. The real humor is that the crack is now re-launched as a new great feature, when it was explicitly excluded for the break-down of REST that it causes.
johnyzee 14y ago
He 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.
- mikescar 14y ago
  Yes, and then you get down to the Kaazing sales pitch, where a diagram shows your packets just going out to the Internet, and there's no longer any management to do on the client. A well written article otherwise though. I appreciated the reminder to audit the headers you're sending out as an easy way to improve performance.
cagenut 14y ago
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 the stack you're turning what was overwhelmingly treated as a request/response model and turning it into a different one. Every cache, proxy, application firewall, traffic shaper, loadbalancer and IDS on both sides is going to 'get confused' and net out to a toooon of user complaints and corner cases.
- strictfp 14y ago
  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 due to the headaches that unrestricted client-server communication causes.
  - rogerbinns 14y ago
    > 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 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.
    - mark_story 14y ago
      I've yet to see an RFC or standard that some developer somewhere didn't totally cock-up. :)
    - 14y ago
halayli 14y ago
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.
- TazeTSchnitzel 14y ago
  The WebSocket protocol isn't part of the HTML5 standard. The API is, but WebSocket's protocol is not defined in HTML5.
  - halayli 14y ago
    The fact that it's mentioned in HTML5 API bothers me.
    - TazeTSchnitzel 14y ago
      Why? They are Web Sockets, and we have AJAX already.
      - halayli 14y ago
        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.
        TazeTSchnitzel 14y ago
        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.
        halayli 14y ago
        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.
lenkite 14y ago
"..., 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
peterlubbers 14y ago
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 ;-)

116 points by SkyMarshal 14y ago

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

TazeTSchnitzel 14y ago
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 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...
- TazeTSchnitzel 14y ago
  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.
  - ralph 14y ago
    As a link, http://websocket.us/ http://websocket.us/
- majke 14y ago
  Shameless plug: SockJS is non-complex alternative to Socket.io, websockets polyfill.
  - TazeTSchnitzel 14y ago
    Added to WebSocket.us, thanks!
SkyMarshal 14y ago
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.
seldo 14y ago
While definitely having an agenda, I still found it a useful high-level guide.
- lbotos 14y ago
  True but some of the data looks to be "dated". According to Wikipedia, Safari, Chrome FF, and IE10 have WS support.
  - SkyMarshal 14y ago
    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?

Liongadev 14y ago

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

strictfp 14y ago

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

ryah 14y ago
"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 cycles: file serving, RPC. There was no "mistake" - it was not a bad fit. There are only expanding use-cases involving existing software infrastructure - for which websockets is solution. That's not to say that HTTP is perfect... It could be better in many ways - but it's ridiculous to write off its success and call it a mistake.
- strictfp 14y ago
  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 makes a lot more sense in that case, and is exactly what WebSockets delivers. One can argue that we were better off with the pure REST web before XmlHttpRequest, in fact I am inclined to agree there, but the crippling of TCP was bound to be cracked. The real humor is that the crack is now re-launched as a new great feature, when it was explicitly excluded for the break-down of REST that it causes.

johnyzee 14y ago

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

mikescar 14y ago
Yes, and then you get down to the Kaazing sales pitch, where a diagram shows your packets just going out to the Internet, and there's no longer any management to do on the client. A well written article otherwise though. I appreciated the reminder to audit the headers you're sending out as an easy way to improve performance.

cagenut 14y ago

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 the stack you're turning what was overwhelmingly treated as a request/response model and turning it into a different one. Every cache, proxy, application firewall, traffic shaper, loadbalancer and IDS on both sides is going to 'get confused' and net out to a toooon of user complaints and corner cases.

strictfp 14y ago
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 due to the headaches that unrestricted client-server communication causes.
- rogerbinns 14y ago
  > 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 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.
  - mark_story 14y ago
    I've yet to see an RFC or standard that some developer somewhere didn't totally cock-up. :)
  - 14y ago

halayli 14y ago

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.

TazeTSchnitzel 14y ago
The WebSocket protocol isn't part of the HTML5 standard. The API is, but WebSocket's protocol is not defined in HTML5.
- halayli 14y ago
  The fact that it's mentioned in HTML5 API bothers me.
  - TazeTSchnitzel 14y ago
    Why? They are Web Sockets, and we have AJAX already.
    - halayli 14y ago
      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.
      - TazeTSchnitzel 14y ago
        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.
        halayli 14y ago
        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.

lenkite 14y ago

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

peterlubbers 14y ago

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 ;-)