Server-Sent Events in Action
-
Upload
andrei-rusu -
Category
Technology
-
view
10.234 -
download
2
description
Transcript of Server-Sent Events in Action
Server Sent EventsIn Action
Andrei RusuMay 30th, 2013
Who is eBuddy?• Web and mobile messaging for
everyone, everywhere!
• Two main messaging products: eBuddy Chat and XMS
• XMS is a real-time messaging app for smartphones
+
• Companion web app
• User needs to register on their mobile client
• Supports several authentication mechanisms
• Designed to bring additional features
• HTML5 draft specification for implementing real-time HTTP streaming
• Enables a web browser to receive push-like notifications from a server
• New EventSource Javascript API
• Implemented in Web XMS - web.xms.me
Server ... what?
Implementation goals
• Improve the scalability of the application in terms of concurrent users
• Speedy communication with the backend service
• Improve the connection handling and stability
• HTML5 makes us look cool
Real-time communicationsThe dark days:
• Polling (short / long lived HTTP requests)
• Comet and reverse ajax
• Never-ending IFRAME(s) / script tags
• Flash sockets (since ActionScript 3)
HTML5 to the rescue!
• New connectivity APIs for scalable client-server messaging
• XHR2, WebSockets, Server-Sent Events
• No more iframe or script tag hacks
XMLHttpRequest Level 2
• Removes cross-domain http restrictions - Cross-Origin Resource Sharing (CORS)
• http://an.example.com can directly connect to http://other.example.org
• Destination server must add some response headers:Access-Control-Allow-Origin: http://an.example.orgAccess-Control-Request-Method: GET, POSTAccess-Control-Request-Headers: X-Requested-WithHost: other.example.org
• More event handlers for tracking the progress of the request
WebSockets
• Full-duplex, bi-directional communication channel
• Client connects to socket server and sends and receives messages real-time
• “Upgrades” an HTTP connection to a WebSocket connection over the same TCP/IP channel
• Works over firewalls and gateways
Server-sent Events
• One-way message streaming over traditional HTTP
• Client subscribes to server and waits (long-lived HTTP channel)
• When there’s data, server generates event and pushes the data to client
• No special server protocol implementation
• New EventSource HTML5 api
EventStream Format
HTTP/1.1 200 OKContent-Type: text/event-stream
data: This is the first message.
event: notificationdata: This is the second message, itdata: has two lines.
id: 12345data: This is the third message with an id
• var source = new EventSource(“https://{backend_server}/subscribe?access_token=XYZ&client_id=123”);source.addEventListener(“open”, function(e) { // connected});
source.addEventListener(“error”, function(e) { switch (this.readyState) { case EventSource.CONNECTING: // trying to reconnect ... break; case EventSource.CLOSE: // connection closed break; }});
source.addEventListener(“message”, function(e) { // message received});
source.addEventListener(“bind_result”, function(e) { var session = JSON.parse(e.data);});
• No HTTP overhead - one single subscribe request
• Updates are streamed real-time
• Publish is done via regular XHR with CORS support
EventSource
Current Architecture
Backend
GET /poll HTTP/1.1
Browser
10s
HTTP/1.1 200 OK: {empty}
55s
HTTP/1.1 200 OK: {message: “Hello there!”, seq=99}
55s
GET /poll HTTP/1.1
HTTP/1.1 200 OK: {empty}
GET /poll HTTP/1.1
Current Web XMS Setup
Client
nginxproxy
POLL
Auth Service
Load balancer
Node.jsservice
LOGIN
Application server 1
Application server 2
Application server NCassandra
1. authorize2. loadbalance3. get_client_settings4. etc.
POLL {server_address}
access_tokenserver_address
settings
access_token
• No direct connections - polls have to go through the proxy
• HTTP Overhead: TCP handshakes, headers, cookies etc.
• Scaling is difficult
Problems with polling
Server-Sent Events Architecture
Backend
new EventSource(‘/subscribe?access_token=XYZ&client_id=ABC)
Browser
close()
id: 1event: bind_resultdata: {session_id: “12143-333-31314124”}
id: 2event: message_receiveddata: {message: “Hello there!”, seq=99}
HTTP/1.1 200 OK text/event-stream
HTTP/1.1 200 OK text/event-stream
New Setup
Client
Auth Service
Load balancer
Node.jsservice
LOGIN
Application server 1
Application server 2
Application server NCassandra
1. authorize2. loadbalance3. get_client_settings4. etc.
EventSource {server_address}
access_tokenserver_address
settings
• Connection is recovered automatically
• Server needs to send keep-alive messages to keep the channel open
• Internet Explorer can emulate EventSource using regular XMLHttpRequest (XDomainRequest in IE9 and below) - polyfill libraries
• Safari doesn’t support EventSource with CORS
Error handling
• EventSource has better browser support and pretty good fallback mechanism
• WebSockets needs HTTP as fallback ultimately
• Long-polling -> EventSource -> WebSocket
Why not WebSockets?