By Pushing Server Data, By Pushing Server Data, We Push the Web ForwardWe Push the Web Forward

Presented by

Philip Ross

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

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

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

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

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

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