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.

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. 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. My Talk
• Trying something different
• Not that many implementation details

4. History of Comet

5. History of Comet - HTTP
• Web's conventional client
request (or "pull") of data
–HTTP

6. History of Comet – Server Push
• Server push of certain
available data to client
– AJAX
– Web 2.0 movement = "Comet"
(Alex Russell, 2006)

7. History of Comet – Early Solutions
• Netscape 1.1 native support
(1995!)
• Java applets

8. Usefulness

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. Broader Applications
• News / Blogs
• Forums
• Everything with content, really!
• A better every-day web user experience

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

13. Costs
• Honestly, server hit can
sometimes get significant
– Bandwidth
– Network
– CPU
– Memory

14. Costs
• Highly depends on the problem
parameters / specs
–Scalability
–Freshness of data
–Frequency of changes
•period = 1 / frequency

15. Costs
• Demands on client
environment
• Implementation labor!

16. Many Ways to Skin a Cat

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

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. 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. Polling
• Supported everywhere
• Very easy to implement
• Good solution for low freshness /
low frequency needs

22. Long Polling

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. 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. Long Polling
• Supported almost everywhere
• Not that hard to implement
• Solid, reliable choice for many
applications

26. Streaming

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. 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. 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. HTML5 Web Sockets

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. 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 http://caniuse.com/

33. How I Think Frameworks Should Do It

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. 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. Comet Frameworks
• XAJAX Comet plugin
• phet
• phpwebsocket
• websocket.js
• jQuery plugin
• socket.io and node.js
• jWebSocket
• NOLOH

37. How NOLOH Does It

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

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. 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. Questions
¿ ?

44. • Check out NOLOH
– http://www.noloh.com
– Intro talk “High Performance WebApps Faster &
Easier with NOLOH” tomorrow by Asher Snyder
• Contact me at pross@noloh.com
Thank You
Presented by
Philip Ross