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