Server-Sent Events in Action

Transcript

1. Server Sent Events In Action Andrei Rusu May 30th, 2013
2. 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
3. +
4. • Companion web app • User needs to register on their mobile client • Supports several authentication mechanisms • Designed to bring additional features
5. • 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?
6. 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
7. Real-time communications The dark days: • Polling (short / long lived HTTP requests) • Comet and reverse ajax • Never-ending IFRAME(s) / script tags • Flash sockets (since ActionScript 3)
8. HTML5 to the rescue! • New connectivity APIs for scalable client-server messaging • XHR2, WebSockets, Server-Sent Events • No more iframe or script tag hacks
9. 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.org
 Access-Control-Request-Method: GET, POST
 Access-Control-Request-Headers: X-Requested-With
 Host: other.example.org • More event handlers for tracking the progress of the request
10. 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
11. 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
12. EventStream Format HTTP/1.1 200 OK Content-Type: text/event-stream ! data: This is the first message. ! event: notification data: This is the second message, it data: has two lines. ! id: 12345 data: This is the third message with an id
13. • 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
14. 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
15. Current Web XMS Setup Client nginx
 proxy POLL Auth Service Load balancer Node.js service LOGIN Application server 1 Application server 2 Application server N Cassandra 1. authorize
 2. loadbalance 3. get_client_settings
 4. etc. POLL {server_address} access_token
 server_address
 settings
 access_token

16. • No direct connections - polls have to go through the proxy • HTTP Overhead: TCP handshakes, headers, cookies etc. • Scaling is difficult Problems with polling
17. Server-Sent Events Architecture Backend new EventSource(‘/subscribe?access_token=XYZ&client_id=ABC) Browser close() id: 1
 event: bind_result
 data: {session_id: “12143-333-31314124”} id: 2
 event: message_received
 data: {message: “Hello there!”, seq=99} HTTP/1.1 200 OK text/event-stream
 HTTP/1.1 200 OK text/event-stream

18. New Setup Client Auth Service Load balancer Node.js service LOGIN Application server 1 Application server 2 Application server N Cassandra 1. authorize
 2. loadbalance 3. get_client_settings
 4. etc. EventSource {server_address} access_token
 server_address
 settings

19. • 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
20. • EventSource has better browser support and pretty good fallback mechanism • WebSockets needs HTTP as fallback ultimately • Long-polling -> EventSource -> WebSocket Why not WebSockets?
21. Thanks!
    visit http://xms.me to download XMS!