Comet: by pushing server data, we push the web forward


Published on

According to the specification of HTTP, which is at the heart of all things web, a client must first request or “pull” information from the server and the server can only issue responses. It is never the other way around, with the server initiating the communication and “pushing” the data as it becomes available. Overcoming this limitation, actually an old and historical problem, would have remarkable applications, benefiting almost every page on the web to various degrees, and significantly enhancing the user experience. And the best part is: you can do it all right now, on any average server environment, and have it work on any standard browser! The modern, Web 2.0 -inspired collection of these solutions, design principles, and techniques for this “sever push technology” is sometimes referred to as “Comet.” I will discuss in detail: the numerous uses and benefits of Comet; the problems and difficulties that developers have to face; the variously accepted solution strategies that exist today including polling, long polling, streaming; their subcategories and their specific implementations, subcategories, advantages, disadvantages, and compatibility nuances; how HTML5 offers to address the issue; as well as outline some original research on the topic. Finally, I will illustrate these concepts and ideas through the live coding of a simple, Comet-based application using the help of a PHP framework with rich Comet support.

Published in: Technology
1 Comment
  • You can add also Aldan 3 as supporting Comet
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Comet: by pushing server data, we push the web forward

  1. 1. By Pushing Server Data,By Pushing Server Data, We Push the Web ForwardWe Push the Web Forward Presented by Philip Ross CometComet co-founder of
  2. 2. Who Am I • Co-Founder of NOLOH – Awesome web development platform – Engineer there about 6 years – Architected and developed their Comet functionality – Along the way, came up with some possibly interesting ideas (and working prototypes) of my own • Contributor to php | architect • Hobbies – Mathematical logic, set theory, etc... – Cheese and beer – Going to cool places like Barcelona Whoa! Deep, man... Whoa! Deep, man...
  3. 3. My Talk • Trying something different • Not that many implementation details
  4. 4. History of Comet
  5. 5. History of Comet - HTTP • Web's conventional client request (or "pull") of data –HTTP
  6. 6. History of Comet – Server Push • Server push of certain available data to client – AJAX – Web 2.0 movement = "Comet" (Alex Russell, 2006)
  7. 7. History of Comet – Early Solutions • Netscape 1.1 native support (1995!) • Java applets
  8. 8. Usefulness
  9. 9. Niche Applications • E-mail web client • Webchat • Collaboration tools • Games • To show a pointless, yet dazzling, demo during your Comet talk at a PHP convention!
  10. 10. Broader Applications • News / Blogs • Forums • Everything with content, really! • A better every-day web user experience
  11. 11. Why Isn’t It Everywhere? • Way too difficult to implement • Not at all approachable to the less skilled developers • Comet discussions keep focusing on the low- level implementation details • Wheel is constantly reinvented • Insufficient progress in the direction of abstraction
  12. 12. Costs
  13. 13. Costs • Honestly, server hit can sometimes get significant – Bandwidth – Network – CPU – Memory
  14. 14. Costs • Highly depends on the problem parameters / specs –Scalability –Freshness of data –Frequency of changes •period = 1 / frequency
  15. 15. Costs • Demands on client environment • Implementation labor!
  16. 16. Many Ways to Skin a Cat
  17. 17. Many Ways to Skin a Cat • Various different implementations / "transport protocols" – Unique advantages and appropriate times to use them • Polling, Long Polling, Streaming, Web Sockets – Specific implementations (e.g., page streaming vs. service streaming)
  18. 18. Polling
  19. 19. Polling • Client periodically connects to server to check for updates • Many connections implies that the largest hit to server performance will be of the network variety
  20. 20. Polling • The lowerlower the duration is than the period, the poorerpoorer the performance will quickly become • The higherhigher the duration is than the period, the poorerpoorer the freshness of data
  21. 21. Polling • Supported everywhere • Very easy to implement • Good solution for low freshness / low frequency needs
  22. 22. Long Polling
  23. 23. Long Polling • Client connects to server, but keeps connection open until server has an update • After update, connection is closed, and after a duration, the process is repeated
  24. 24. Long Polling • Many simultaneous pending connections means server CPU and memory might take a hit • As frequency becomes high, long polling becomes like polling, taking a considerable network hit on server
  25. 25. Long Polling • Supported almost everywhere • Not that hard to implement • Solid, reliable choice for many applications
  26. 26. Streaming
  27. 27. Streaming • Client connects to server and stays connected for as long as it can • Server keeps feeding updates through the same connection as they become available
  28. 28. Streaming • Many simultaneous pending connections means server CPU and memory might take a hit • Very efficient network-wise • Great for high-frequency (almost real-time) applications
  29. 29. Streaming • Not supported by servers that can't flush output buffers • Nightmare to implement – Different browsers require various different hacks – IE requires altogether different "htmlfile" solution
  30. 30. HTML5 Web Sockets
  31. 31. HTML5 Web Sockets • Browser can actually open and listen on ports, effectively trading the client/server role as it sees fit • Server can contact browser directly, precisely when necessary without extra overhead • Perfect for low-medium frequency applications – For real-time levels, streaming might still be the way to go
  32. 32. HTML5 Web Sockets • Currently in "Working Draft" phase • Support remains extremely limited • Even when supported in all browsers, supporting legacy browsers will still be an issue Grid courtesy of
  33. 33. How I Think Frameworks Should Do It
  34. 34. How I Think Frameworks Should Do It • No necessary server installation – Supporting servers optionally is nice • Support for all reasonably major browsers (e.g., IE6+) • Since different transport protocols are fit for different applications, they should all be supported – ContrastContrast: many tools today support only long polling
  35. 35. How I Think Frameworks Should Do It • Hide / abstract away as much of the communication layer as possible – ContrastContrast: many tools are server-only or client-only. Developer must still be very aware of the extreme complexities of client/server interaction • Hide / abstract away as much of the data layer as possible – Developer merely indicates where the data is – Rely on framework to detect when data has changed – Event-driven: Have the framework invoke your callback – ContrastContrast: many tools require reuse of same data logic
  36. 36. Comet Frameworks • XAJAX Comet plugin • phet • phpwebsocket • websocket.js • jQuery plugin • and node.js • jWebSocket • NOLOH
  37. 37. How NOLOH Does It
  38. 38. How NOLOH Does It • Listener Control – Intended to listen to a source of data, and upon detecting changes, it triggers some defined method – A very unintimidating thing to throw into any application for developers of a very wide range of skill levels
  39. 39. How NOLOH Does It • Source property – File, database query, web service, a method that returns data, or you can write your own • Update property (Event) – Gets triggered upon detecting changes • Transport property [optional] – Currently can be: Polling, Long Polling, or Streaming. Others are on the way
  40. 40. Original Research
  41. 41. Original Research • Similar to polling except server will not actually establish connection with browser when there are no updates • Server will protect itself from browser connections in the same way firewalls protect against denial-of-service attacks • When server has updates, then it will listen to browsers
  42. 42. Original Research • Great for low-medium frequency applications –Especially in the absence of availability of web sockets • Still experimental, but early tests look promising
  43. 43. Questions ¿ ?
  44. 44. • Check out NOLOH – – Intro talk “High Performance WebApps Faster & Easier with NOLOH” tomorrow by Asher Snyder • Contact me at Thank You Presented by Philip Ross