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?

Thanks!visit http://xms.me to download XMS!