3. Polling
• “Simulate” real-time by making series of XHRs
at regular intervals.
• Pulls Data from the server.
Process Process
Web Server Process Process Process
Respo
Respo
Respo
Respo
Respo
st
st
st
st
st
Reque
Reque
Reque
Reque
Reque
nse
nse
nse
nse
nse
Browser
4. Problems with Polling
• Its a wasted request if there are no updates.
• Vice-versa, users may be working on “stale”
data since the last update
• Each request creates new connection to the
server.
• Each request causes exchange of HTTP headers
(request and response), they consume
Bandwidth.
• Not scalable
5. Long-Polling
• Solves the problem of extremes (wasted request
or stale data) by pushing updates to clients as they
happen.
Process Process
Web Server
Respo
Process Process Process
Resp
Res
Respon
Respon
est
st
uest
Request
Request
Reque
Requ
pon
onse
Req
nse
se
se
se
Browser
6. How Long-Polling works
• Browser makes request to the server.
• Connection is kept open between the server and
the browser.
• When an update arrives the connection is closed
(sent as complete response 200 OK).
• The browser then initiates a new long-polling
request for subsequent updates.
• Techniques
• XHR Style LP • IFrame
• Script Tag LP
7. Long-Polling Pros & Cons
• Pros
• Reduces latency for data-delivery.
• Cons.
• Each request creates new connection and causes
exchange of HTTP headers, they consume Bandwidth.
• Not Scalable
• Request hangs until a response is ready to be delivered.
• Old Server software won’t work with this approach as they hold the thread
for each request.
8. Long-Polling Scalability
• It demands a server software that does not
hold thread on server for each request.
• Instead move towards asynchronous event-
driven server architecture
• For e.g Nginx, Netty, Node.js etc... Servers
• Addresses the C10K (Concurrent 10,000
connections) problem
9. Separate Upstream &
Downstream connections
• Downstream Connection.
• Is kept open between the server and the browser.
• Regular updates pushed through this connection.
• Messages are continuously parsed by the client as
they arrive.
• Upstream Connection
• Browser makes Ajax requests to send commands (i.e
events that trigger action) to server.
10. Separate Connections:
Pros & Cons
• Pros
• Offers lowest latency.
• Best for streaming needs.
• Cons
• Uses 2 Half-Duplex connections to simulate Full-
Duplex.
• HTTP is a request/response protocol (Half-Duplex), not bi-directional
• Co-ordination overheads between two connections.
• Some browsers may not support more than two
simultaneous connections.
11. Enter WebSockets
• Full-Duplex
• Exchange HTTP headers initially when the connection is
established, after that its all data exchange.
• Uses less bandwidth.
• Significant Scalability with reduction in network
traffic
• 100 clients.
• 100 * 10 clients.
• 100 * 10 * 10 clients.
13. Check Browser Support
• Use window.WebSocket to find out
• What to do if the browser does not support it?
• use polyfills (github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills)
• SockJS
• Atmosphere jQuery Plugin (Fallback to LP)
• Socket.io
• web-socket-js (Flash based)
• Kaazing Websocket Gateway (Commercial)
• Graceful Websocket jQuery Plugin (Fallback to LP)
• jQuery Socket (Supports WebSocket, Server-Sent Events, Streaming and LP)
14. WebSocket Servers
Java .NET Python Ruby PHP
Extendible
Jetty SuperWebSocket websockify Goliath Web Socket
Server
web-socket-
jWebSocket Nugget pywebsockets
ruby
Netty XSockets
GlassFish
Apache Active MQ
Tomcat
15. Architecture
1
Request Web
2 Serve Static Resources
Server
3 Initiate WebSocket Connection
4 Upgrade Connection
5 Send Data WebSocket
6 Receive Data
Server
Event driven on both sides of the WebSocket connection.
16. Async API
• Server Callbacks
• onopen - when the connection is established
• onclose - when the connection is closed
• onerror - when an error occurs
• onmessage - when a message is received from the
server
• Client Transmissions
• send
17. How WS protocol works
• When making a WS
connection, initiated by
HTTP request, client sends a
connection “upgrade”
request.
• Server responds by
upgrading the connection
and switching protocols
• Handshake is complete when both client & server switch
protocols
• After this, client and server can begin sending messages until
• either of them closes the connection
• there is some network problem
19. Same-Origin Policy
• Prevents client-Side Webapp running from one
origin to obtain data retrieved from another
origin.
• Limits unsafe HTTP requests launched
towards destinations that differ from the
running application’s origin
• <script> element can execute content retrieve
from foreign origins.
• Requires you to trust the server
• Bypass using JSONP
• Server needs to implement some logic to allow you to do this.
20. Cross-Origin Resource
Sharing (CORS)
• Extends Same-Origin Policy
• Its a way of restricting the domains that can access
services.
• White-list domains that are allowed to access services
• The browser and in-browser applications are
supposed to respect that, and sometimes the
Services (server-side) may protect themselves.
• Use a CORS Filter
• Flash uses crossdomain.xml
