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

By Pushing Server Data, We Push the Web Forward Presented by Philip Ross Comet co-founder of

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

My Talk
Trying something different
Not that many implementation details

History of Comet

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

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

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

Usefulness

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!

Broader Applications
News / Blogs
Forums
Everything with content, really!
A better every-day web user experience

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

Costs
Honestly, server hit can sometimes get significant
Bandwidth
Network
CPU
Memory

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

Costs
Demands on client environment
Implementation labor!

Many Ways to Skin a Cat

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)

Polling

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

Polling
The lower the duration is than the period, the poorer the performance will quickly become
The higher the duration is than the period, the poorer the freshness of data

Polling
Supported everywhere
Very easy to implement
Good solution for low freshness / low frequency needs

Long Polling

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

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

Long Polling
Supported almost everywhere
Not that hard to implement
Solid, reliable choice for many applications

Streaming

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

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

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

HTML5 Web Sockets

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

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/

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
Contrast : many tools today support only long polling

Hide / abstract away as much of the communication layer as possible
Contrast : 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
Contrast : many tools require reuse of same data logic

Comet Frameworks
XAJAX Comet plugin
phet
phpwebsocket
websocket.js
jQuery plugin
socket.io and node.js
jWebSocket
NOLOH

How NOLOH Does It

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

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

Original Research

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

Original Research
Great for low-medium frequency applications
Especially in the absence of availability of web sockets
Still experimental, but early tests look promising

Questions ¿ ?

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

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

by NOLOH LLC.

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

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