Upload
folio3-software
View
164
Download
2
Tags:
Embed Size (px)
Citation preview
HTTP Server Push HTTP Server Push TechniquesTechniques
www.folio3.com@folio_3
Folio3 – OverviewFolio3 – Overview
www.folio3.com @folio_3
Who We Are
We are a Development Partner for our customers
Design software solutions, not just implement them
Focus on the solution – Platform and technology agnostic
Expertise in building applications that are:
Mobile Social Cloud-based Gamified
What We Do Areas of Focus
Enterprise
Custom enterprise applications
Product development targeting the enterprise
Mobile
Custom mobile apps for iOS, Android, Windows Phone, BB OS
Mobile platform (server-to-server) development
Social Media
CMS based websites for consumers and enterprise (corporate, consumer,
community & social networking)
Social media platform development (enterprise & consumer)
Folio3 At a Glance Founded in 2005
Over 200 full time employees
Offices in the US, Canada, Bulgaria & Pakistan
Palo Alto, CA. Sofia, Bulgaria
Karachi, Pakistan
Toronto, Canada
Areas of Focus: Enterprise Automating workflows
Cloud based solutions
Application integration
Platform development
Healthcare
Mobile Enterprise
Digital Media
Supply Chain
Areas of Focus: Mobile Serious enterprise applications for Banks,
Businesses
Fun consumer apps for app discovery,
interaction, exercise gamification and play
Educational apps
Augmented Reality apps
Mobile Platforms
Some of Our Mobile Clients
Areas of Focus: Web & Social Media
Community Sites based on
Content Management Systems
Enterprise Social Networking
Social Games for Facebook &
Mobile
Companion Apps for games
Some of Our Web Clients
HTTP Server Push HTTP Server Push TechniquesTechniques
www.folio3.com @folio_3
Agenda Existing HTTP Protocol Architecture
Traditional Methods for Server Push Polling Long Polling / Comet Pushlets / Streaming
Comet in detail Possible issues with Comet and their solutions Comet Demonstration : MediaMorph
Where does HTML5 fit-in?
HTML 5 Server Sockets
Existing HTTP Protocol Architecture Existing HTTP
Stateless protocol
Request – Response … The end !
Client initiated communication, Always !
Server is forgetful
AJAX comes for help
Traditional Methods : Polling Polling
Periodic requests by the client
Time between requests would always be N time units
Traditional Methods : Polling Merits
Works better with very high frequency updates
May suit a very fast / frequent updating system
Very simple to implement, mostly easiest of all methods
Works with ancient systems too
Traditional Methods : Polling De-Merits
Too much network overhead
At times slower than expected results
The updates would always come after N time units
Possibly too many unnecessary requests
Possible browser performance degradation on the client side
Does not allow cross-domain access
Traditional Methods : Long Polling Long Polling / Comet
Client requests and waits for the server to respond
The server only responds back when there is any update or data available
Traditional Methods : Long Polling Merits
Behaves very similar to what a real server push mechanism would do
Immediate response in case of an update from the server
Comparative to Polling very low network overhead and request count
Works with most old and new systems
Works even with IE 6 !!!
Traditional Methods : Long Polling De-Merits
Slightly more complex to implement than polling
May not work well with very frequent updates
Needs special server & client configurations
Needs to take into account the Read Timeout enforcements by intermediate gateway or proxies
Does not allow cross-domain access
Traditional Methods : Streaming Streaming / Pushlet
One request to the server
Infinitely long response with continuous messages from the server
Client does not talk back unless with a new request
Javascript <Script> tag enclosed code snippets
Script tag’s URL would be a comet server side URL. Sending Javascript code snippets time to time.
Traditional Methods : Streaming Merits
Behaves very similar to what a real server push mechanism would do
Allows cross-domain implementations, since javascript urls can be cross-domain
Immediate response in case of an update from the server
Possibly very low network overhead
Negligible request count
Traditional Methods : Streaming De-Merits
May not be supported by some old systems
May cause browser memory overhead because of a long list of script tags executed on the page
Client is unable to send new request parameters in normal scenarios
All post-event logic needs to be written on the server side
Proxy servers could buffer responses causing issues
Possible issues with Comet and their solutions
Read timeout
Orphaned requests
Very frequent updates – Hybrid Poll – Push.
Comet DemonstrationComet Demonstration
www.folio3.com @folio_3
Where does HTML5 fit-in?
HTML5 offers many solutions addressing issues with existing architectures
One of the solutions is WebSockets
WebSockets address almost all issues with the existing systems
HTML5 WebSockets HTML5 WebSockets
Provides bi-directional, full-duplex communications channels
New URL schems ws:// - For Plain WebSocket wss:// - For Secure WebSocket
Very low network overhead
Only one request, true full-duplex communication
Still a long way to go. It is substantial infrastructural change
How HTML5 WebSockets Work ? Four step lifecycle
Browser Requests
Server Responds with Acknowledgement Tokens
Connection Establishment for Two way communication
Connection closed by either party
Contact
For more details about our
services, please get in touch with
us.
US Office: (408) 365-4638
www.folio3.com