The document discusses the implementation and benefits of server-sent events and other real-time messaging technologies for enhancing web and mobile messaging applications like eBuddy. It highlights improvements in scalability, connection handling, and real-time communication through HTML5 features such as WebSockets and EventSource. The document also contrasts traditional polling methods with more efficient server-sent events and outlines the architecture necessary for these modern solutions.

1. Server Sent EventsIn 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 NCassandra
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 NCassandra
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!