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
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
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?