Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

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

on

  • 4,813 views

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

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.

Statistics

Views

Total Views
4,813
Views on SlideShare
4,811
Embed Views
2

Actions

Likes
2
Downloads
109
Comments
1

2 Embeds 2

http://www.techgig.com 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • You can add also Aldan 3 as supporting Comet
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 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
  • 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
  • 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
  • How I Think Frameworks Should Do It
    • 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