Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The HTML5 WebSocket API

An introduction to the HTML5 WebSocket API for Stockholm Web Monkeys.

  • Login to see the comments

The HTML5 WebSocket API

  1. 1. The HTML5 WebSocket API Stockholm Web Monkeys
  2. 2. $ whoami David Lindkvist Application Developer @F_i Web development is my passion! Drummer 2
  3. 3. Agenda Why do we need WebSockets? What is it? How does it work? When can we use it? 3
  4. 4. Why? 4
  5. 5. Why? Today’s web apps demand reliable event-driven communications “Real-time” (minimal latency) Full duplex Examples: Social networking Online games Collaborative platforms Financial applications etc... 5
  6. 6. Why? Problems with HTTP... It’s hard to achieve real-time apps, primarily due to the limitations of HTTP HTTP is half-duplex (traffic flows in only one direction at a time) HTTP adds latency and message overhead 6
  7. 7. Why? Simulate real-time? Polling (AJAX) Poll server for updates, wait at client Long polling (Comet) Poll server for updates, wait at the server; uses two connections and requires unnecessary complexity Used in Ajax applications to simulate real-time Leads to poor resource utilization... 7
  8. 8. Why? Polling #$%%&'()*+,-&./,.0+/ !""#$%&"'()'"'$*+&,!&')- (picture from Kaazing) !"#$"%$!$ 1)233")4 5667&'()8$+9$+6.&$' !"#$"%$!$ !" !" 8
  9. 9. Why? Long Polling #$%&'($))*%&+,-./*01.02-1 (picture from Kaazing) !"#$"%$!$ 3+!""4+5 6778*%&+9$-:$-70*$% !"#$"%$!$ !" !" 9
  10. 10. Why? HTTP req/res overhead GET /PollingStock//PollingStock HTTP/1.1 Host: localhost:8080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20091102 Firefox/3.5.5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 691 chars Connection: keep-alive Referer: http://localhost:8080/PollingStock/ Cookie: showInheritedConstant=false; showInheritedProtectedConstant=false; showInheritedProperty=false; showInheritedProtectedProperty=false; showInheritedMethod=false; showInheritedProtectedMethod=false; showInheritedEvent=false; showInheritedStyle=false; showInheritedEffect=false HTTP/1.x 200 OK X-Powered-By: Servlet/2.5 Server: Sun Java System Application Server 9.1_02 Content-Type: text/html;charset=UTF-8 Content-Length: 321 Date: Sat, 07 Nov 2009 00:32:46 GMT Total 871 chars (example from Kaazing) 10
  11. 11. Why? Header traffic analysis Example network throughput for Polling HTTP req/resp headers: Use case A: 10,000 clients polling every 60 seconds Network throughput is (871 x 10,000)/60 = 145,166 bytes = 1,161,328 bits per second (1.1 Mbps) Use case B: 10,000 clients polling every second Network throughput is (871 x 10,000)/1 = 8,710,000 bytes = 69,680,000 bits per second (66 Mbps) Use case C: 100,000 clients polling every 10 seconds Network throughput is (871 x 100,000)/10 = 8,710,000 bytes = 69,680,000 bits per second (66 Mbps) (example statistics from Kaazing) 11
  12. 12. What? 12
  13. 13. What is a WebSocket? W3C/IETF Standard Uses the WebSocket protocol instead of HTTP True full-duplex communication channel Both UTF-8 strings and binary frames can be sent in any direction at the same time It’s not a raw TCP socket 13
  14. 14. What is a WebSocket? Connection established by “upgrading” from HTTP to WebSocket protocol Runs via port 80/443 - Proxy/Firewall friendly HTTP-compatible handshake Integrates with Cookie based authentication WebSockets and Secure WebSockets ws:// wss:// 14
  15. 15. What? Upgrade handshake // browser request to the server GET /demo HTTP/1.1 Upgrade: WebSocket Connection: Upgrade Host: Origin: WebSocket-Protocol: sample // server response HTTP/1.1 101 Web Socket Protocol Handshake Upgrade: WebSocket Connection: Upgrade WebSocket-Origin: WebSocket-Location: ws:// WebSocket-Protocol: sample 15
  16. 16. What? Reduces Network Traffic Each message (“frame”) has only 2 bytes of overhead No latency from establishing new TCP connections for each HTTP message No polling overhead - only sends messages when there is something to send 16
  17. 17. What? Header traffic analysis Example network throughput for WebSocket req/res headers: Use case A: 10,000 frames every 60 seconds Network throughput is (2 x 10,000)/60 = 333 bytes = 2,664 bits per second (2.6 Kbps) [was 1.1 Mbps] Use case B: 10,000 frames every second Network throughput is (2 x 100,000)/1 = 20,000 bytes = 160,000 bits per second (156 Kbps) [was 66 Mbps] Use case C: 100,000 frames every 10 seconds: Network throughput is (2 x 100,000)/10 = 20,000 bytes = 160,000 bits per second (156 Kbps) [was 66 Mbps] (example statistics from Kaazing) 17
  18. 18. What? Overheard "Reducing kilobytes of data to 2 bytes...and reducing latency from 150ms to 50ms is far more than marginal. In fact, these two factors alone are enough to make WebSocket seriously interesting to Google.“ - Ian Hickson (Google, HTML5 spec lead) 18
  19. 19. How? 19
  20. 20. How? The WebSocket interface [Constructor(in DOMString url, in optional DOMString protocol)] interface WebSocket { readonly attribute DOMString URL; // ready state const unsigned short CONNECTING = 0; const unsigned short OPEN = 1; const unsigned short CLOSING = 2; const unsigned short CLOSED = 3; readonly attribute unsigned short readyState; readonly attribute unsigned long bufferedAmount; // networking attribute Function onopen; attribute Function onmessage; attribute Function onerror; attribute Function onclose; boolean send(in DOMString data); void close(); }; WebSocket implements EventTarget; 20
  21. 21. How? The Javascript client connect: function () { try { = new WebSocket(’ws://’); = function (event) {/*...*/}; = function (event) {/*...*/}; = messageListener; } catch(exception) {} }, messageListener: function (event) { alert(’New message: ’ + }, send: function (message) { if ( {; } }, 21
  22. 22. How? The server Server implementations (mostly experimental): Kaazing WebSocket Gateway (production since april 2009) phpwebsockets web-socket-ruby mod_pywebsocket JWebSocket Jetty WebSocketServlet and many more... 22
  23. 23. How? Jetty server example public class MyServlet extends HttpServlet implements Servlet { // trigger on HTTP GET request public void doGet(HttpServletRequest req, HttpServletResponse res) {} // trigger on HTTP POST request public void doPost(HttpServletRequest req, HttpServletResponse res) {} // doWebSocket() ??? } 23
  24. 24. How? Jetty server example public class ChatServiceServlet extends WebSocketServlet implements Servlet { public void doGet(HttpServletRequest req, HttpServletResponse res) {} public void doPost(HttpServletRequest req, HttpServletResponse res) {} // trigger on request to upgrade to WebSocket connection protected WebSocket doWebSocketConnect(HttpServletRequest req, String arg) { return new ChatWebSocket(); } // shared resource - needs to be thread safe! Set<ChatWebSocket> clients = new CopyOnWriteArraySet<ChatWebSocket>(); class ChatWebSocket implements WebSocket { /* impl on next slide... */ } } 24
  25. 25. How? Jetty server example class ChatWebSocket implements WebSocket { Outbound outbound; public void onConnect(Outbound outbound) { this.outbound = outbound; clients.add(this); } public void onMessage(byte frame, String data) { for (ChatWebSocket socket : clients) { try { socket.outbound.sendMessage(frame, data); } catch(IOException e) {} } } public void onDisconnect() { clients.remove(this); } } 25
  26. 26. How? It’s not a silver bullet How should we handle the “close” event? Application must be prepared to reopen connection if close event was triggered unexpectedly Idle timeout Network errors 26
  27. 27. How? It’s not a silver bullet Keep-alives Sending keep-alive messages to prevent closing due to an idle timeout No timeout discovery available on the WebSocket Keep-alives don’t avoid the need for handling “close” events WiFi connections and mobile devices 27
  28. 28. How? It’s not a silver bullet Queues Buffer messages that failed to send due to a transient network problem Resend queue when connection is restored Important for both server and client 28
  29. 29. How? It’s not a silver bullet Timeouts Not all network problems are transient Can’t allow queues to grow for ever Applications need a timeout when user is considered to be disconnected Need to implement an explicit close message for application to distinguish between network failures and an orderly close 29
  30. 30. How? It’s not a silver bullet Message Retries Even with queues we can’t know for sure messages are delivered due to race condition If close event is triggered soon after a message was sent? For quality of service to be guaranteed an acknowledge message would have to be sent for each message Ideally a future version of WebSockets would support an orderly close event 30
  31. 31. How? It’s not a silver bullet onclose handing, keep-alives, message queues, timeouts and retries, introduce more problems: If server goes down client will loop trying to reconnect Needs a retry backoff algorithm to reduce retries over time Message size can cause connection to die if it exceeds some resource limit on client or server Looks like a transient network error... Connection is restored and retries to send same message from queue... Infinite loop! 31
  32. 32. When? 32
  33. 33. When? Current browser support: CHROME 33
  34. 34. When? Browser support Status of native WebSocket support for other browsers (2010-04-11): Firefox - targeted for the v3.7 release but not yet in 3.7a4pre Safari - announced for 4.x but no target date yet Opera - 10.x already 95% HTML5 compatible but WebSockets missing IE 8.x - 9.x unknown (reference: jWebSocket project) 34
  35. 35. When? Graceful degradation for the next ~10 years.... Realtime apps: Java Applet TCP Socket Flash XMLSockets over TCP Long polling over HTTP Not so realtime apps: Polling using periodical pulls over HTTP 35
  36. 36. When? Providing fallbacks mean more work. More works sucks.. Solution: Look for a client library which implements the WebSocket interface! Kaazing jWebSocket Users will be able to take advantage of true WebSockets when their browser supports it 36
  37. 37. When? Or... roll your own! Introducing the Graceful WebSocket: A jQuery plugin implementing the WebSocket interface One interface = one implementation Uses the native WebSocket if available Automatic fallback on HTTP polling 37
  38. 38. Get involved? Visit the Graceful WebSocket project over at Google Code: 38
  39. 39. Summary Allows us to write real-time, event driven applications Better resource utilization, less latency, less network overhead Browser support so far is poor Specification is not finalized 39
  40. 40. References? W3C The WebSocket API HTML5 Communications - Frank Greco (Kaazing) jfokus 2010 Greg Wilkins Jetty WebSocket Server Greg Wilkins Websocket Chat 40
  41. 41. Thanks! oh... and we are hiring! 41