Comet / WebSocket Web Applications

18,852
-1

Published on

La presentazione tenuta da Simone Bordet in occasione del Codemotion Roma del 5 marzo 2011 - http://www.codemotion.it/

Si parlerà delle web applications di tipo Comet, cioè di quelle web applications che si occupano di notificare con latenza bassissima - di norma a browsers - eventi ricevuti dal server come stock price, eventi sportivi, giochi online, etc. La sessione proseguirà con una discussione sugli impatti che le applicazioni Comet hanno nello sviluppo e nel deployment, e con una panoramica sul nuovo protocollo WebSocket definito da HTML5 e sul progetto open source CometD.

Published in: Technology
0 Comments
11 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
18,852
On Slideshare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
0
Comments
0
Likes
11
Embeds 0
No embeds

No notes for slide

Comet / WebSocket Web Applications

  1. 1. Comet and WebSocket Web Applications Simone Bordet [email_address] How to Scale Server-Side Event-Driven Scenarios
  2. 2. Agenda <ul><li>What are Comet web applications ?
  3. 3. Impacts of Comet web applications
  4. 4. WebSocket web applications
  5. 5. The CometD project
  6. 6. Questions & Answers </li></ul>
  7. 7. What are Comet & WebSocket Web Applications ?
  8. 8. Web 1.0 Applications <ul><li>Web Classic Interaction </li></ul><ul><li>Request Pattern </li><ul><li>Bursts of requests for HTML, images, CSS, JS </li></ul><li>Navigation Mode </li><ul><li>Full page based </li></ul><li>Interaction with Server </li><ul><li>Reactive, changes happen on user click
  9. 9. Resources download </li></ul></ul>
  10. 10. Ajax Web Applications <ul><li>Web Classic + XMLHttpRequest (XHR) </li></ul><ul><li>Request Pattern: changed </li><ul><li>Bursts (for classic) + Concurrent (for XHR)
  11. 11. Requires synchronization in server code </li></ul><li>Navigation Mode: radically changed </li><ul><li>Sometimes full page, most often single page with partial changes </li></ul><li>Interaction with Server: changed </li><ul><li>Reactive as before
  12. 12. Data download </li></ul></ul>
  13. 13. Comet Web Applications <ul><li>Web Classic + Ajax + WebSocket </li></ul><ul><li>Request Pattern, Navigation Mode, Interaction with Server </li><ul><li>Same as with XHR </li></ul><li>More Efficient </li><ul><li>Now messages can be server-initiated
  14. 14. Messages do not require a response </li></ul><li>Uses JavaScript </li><ul><li>Same as with XHR </li></ul></ul>
  15. 15. Rich User Interfaces <ul><li>Traditional Web sacrificed Rich UI for: </li><ul><li>Ubiquitous access
  16. 16. Zero Install </li></ul><li>Heavy usage of client-side JavaScript and XHR changed the way we create and develop webapps </li><ul><li>They become rich , and raise expectations </li></ul><li>Server side events are needed </li><ul><li>To meet user raised expectations
  17. 17. To implement new types of web applications </li></ul></ul>
  18. 18. Comet Examples
  19. 19. Polling for Server Side Events <ul><li>Polling Strategy for Server-side Events Notification </li><ul><li>Simple to implement (“I can do that !”)
  20. 20. Sensible latency </li></ul></ul><ul><li>Can look like a denial of service (DoS) attack to the poor server </li><ul><li>When poll interval is short
  21. 21. When the number of clients is large </li></ul></ul>
  22. 22. Long Polling for Server-side events <ul><li>Comet Strategy </li><ul><li>More difficult to implement correctly
  23. 23. Minimal latency </li></ul></ul><ul><li>The “long poll” request is held by the server until: </li><ul><li>A server-side event arrives
  24. 24. A timeout expires
  25. 25. The client disconnects </li></ul></ul>
  26. 26. Websocket for Server-side events <ul><li>WebSocket strategy </li><ul><li>More efficient than long poll
  27. 27. True bidirectional web communication </li></ul></ul><ul><li>WebSocket Messages </li><ul><li>No more Request & Response </li></ul><li>Not widely deployed yet
  28. 28. Messages can be initiated by the server </li></ul>
  29. 29. WebSocket <ul><li>From HTML 5 </li><ul><li>API & Protocol
  30. 30. Two way communication </li></ul><li>Developed by WHATWG </li><ul><li>Browser vendors
  31. 31. Little server side input </li></ul><li>In IETF WG </li><ul><li>Developing standard
  32. 32. Slow progress </li></ul><li>Experimentally Deployed </li><ul><li>Chrome, Opera, Firefox </li></ul></ul>interface WebSocket { attribute Function onopen; attribute Function onmessage; attribute Function onerror; attribute Function onclose; boolean send(in String data); void close(); };
  33. 33. Impacts on the Server
  34. 34. Scaling Polling <ul><li>Scaling Polling </li><ul><li>1000 clients, each polling every 5 seconds
  35. 35. Request Rate: 200 requests/s
  36. 36. Latency: 2.5 seconds in average, too high </li></ul><li>How can polling achieve, say, 250 ms latency ? </li><ul><li>Reduce the polling interval to 0.5 seconds
  37. 37. Request Rate: 2000 requests/s, pretty high </li></ul><li>Limits </li><ul><li>Most likely, the server is CPU bound, then connection bound </li></ul></ul>
  38. 38. Scaling Comet (Blocking) <ul><li>Scaling Comet (long polling) </li><ul><li>1000 clients, long poll request held for 20 seconds
  39. 39. Request Rate: 50 requests/s, good
  40. 40. But yields 1000 concurrent requests ! </li><ul><li>Running out of threads in the pool
  41. 41. On 64-bit JVM the thread stack size is 1 MB </li></ul></ul><li>Latency </li><ul><li>Average latency approaches network latency
  42. 42. Maximal latency is at least 3x network latency </li></ul><li>Limits </li><ul><li>Most likely, the server is memory bound
  43. 43. Note that threads stack memory is outside Java heap </li></ul></ul>
  44. 44. Scaling Comet <ul><li>Comet has huge impacts on server-side
  45. 45. You cannot just deploy your Comet web application in a standard configuration
  46. 46. You cannot deploy your Comet application behind Apache Httpd & other intermediaries </li><ul><li>Do not scale for the same reasons </li></ul><li>You need a new generation of servers </li></ul>
  47. 47. Asynchronous Servers <ul><li>Jetty Server explored these problems in the Servlet(TM) space for JMS messaging.
  48. 48. The Jetty Continuations allow the Jetty Server to threadlessly suspend requests
  49. 49. The continuation concepts have been incorporated in the new Servlet(TM) 3.0 specification
  50. 50. Jetty 6 and Jetty 7 successfully deployed Comet applications worldwide
  51. 51. Jetty 8 implements the Servlet(TM) 3.0 specification </li></ul>
  52. 52. Blocking Comet <ul><li>Server-side Event-driven Comet Web Application </li></ul>
  53. 53. Asynchronous Comet <ul><li>Server-side Event-driven Comet Web Application </li></ul>
  54. 54. Scaling Comet (Asynchronous) <ul><li>Comet (Asynchronous) </li><ul><li>1000 clients, long poll request held for 20 seconds
  55. 55. Wait for server-side events is threadless
  56. 56. Request is re-run on event arrival or on long poll timeout
  57. 57. Request Rate: 100 requests/s, good
  58. 58. Only few concurrent active (threaded) requests
  59. 59. Good latency, good request rate, no thread pool problems </li></ul><li>Limits </li><ul><li>Most likely, the server is connection bound, then CPU bound
  60. 60. Scales a lot better than normal polling and blocking Comet </li></ul></ul>
  61. 61. Scaling Comet (WebSocket) <ul><li>WebSocket </li><ul><li>1000 clients, keepalive message every 20 seconds </li><ul><li>No need to reply, decreased bandwidth </li></ul><li>Wait for server-side events is threadless
  62. 62. Request Rate: 50 requests/s, good
  63. 63. Only few concurrent active (threaded) requests
  64. 64. Optimal latency, good request rate, no thread pool problems </li></ul><li>Limits </li><ul><li>Most likely, the server is connection bound, then CPU bound
  65. 65. Scales a slightly better than Comet with continuations due to better data density and reduced request rate </li></ul></ul>
  66. 66. The Need of a Framework <ul><li>With Comet, we have an asynchronous bidirectional web </li><ul><li>Looks like messaging to me </li></ul><li>Writing server-side code based on continuations (or, in the future, with Servlet 3.0) is difficult </li><ul><li>It really is, you don't want to do it </li></ul><li>How are failures handled? </li><ul><li>Timeouts, dropouts, retries, backoffs, cross domain, etc. </li></ul><li>Web applications should be easy to write </li><ul><li>Can we abstract the gory details into a library ? </li></ul></ul>
  67. 67. The CometD Project
  68. 68. The CometD Project <ul><li>We have now a scalable bidirectional web
  69. 69. What do we need to write applications ?
  70. 70. We don't want to care about: </li><ul><li>Which transport: long-polling, websocket
  71. 71. limits: same-origin policy, two connection limits </li></ul><li>We want: </li><ul><li>A clean way to publish data to the server
  72. 72. A clean way to receive data from the server
  73. 73. A clean way to “emit” server-side events to clients </li></ul></ul>
  74. 74. CometD JavaScript API var cometd = $.cometd; // jQuery style cometd. init ('http://myserver/cometd'); cometd. subscribe ('/my/channel', function(message) { var data = message.data; // Do something with the data }); cometd. publish ('/my/channel', { chatText: 'hello!' }); cometd. disconnect ();
  75. 75. The CometD Project <ul><li>There are a lot of other details to take care of </li><ul><li>Transport Negotiation </li><ul><li>WebSocket, Long Polling over CORS, JSONP, etc. </li></ul><li>Authentication
  76. 76. Network Failures </li><ul><li>With possible automatic retry </li></ul><li>Message Batching
  77. 77. Message Acknowledgment
  78. 78. Message serialization
  79. 79. Etc. </li></ul><li>From these and other requirements and input, the CometD project was born </li></ul>
  80. 80. The CometD Project <ul><li>The CometD project delivers libraries that use the Comet technique (long poll) or WebSocket to transport Bayeux messages
  81. 81. The Bayeux protocol specifies the format of the Bayeux messages </li><ul><li>It is based on JSON </li></ul><li>Libraries are available in </li><ul><li>JavaScript (client)
  82. 82. Java (client and server)
  83. 83. Perl & Python (less active) </li></ul></ul>
  84. 84. Bayeux <ul><li>Bayeux is at its core a publish/subscribe messaging system </li><ul><li>Very similar to JMS publish/subscribe </li></ul><li>A Bayeux channel is similar to a JMS Topic </li><ul><li>You may subscribe to it
  85. 85. You will be delivered messages published onto </li></ul><li>You can publish messages to a channel </li><ul><li>The server automatically delivers the messages to all channel subscribers </li></ul></ul>
  86. 86. CometD JavaScript <ul><li>The JavaScript library features </li><ul><li>Common code with bindings for Dojo and jQuery
  87. 87. Highly configurable
  88. 88. Message batching
  89. 89. Automatic reconnection
  90. 90. Pluggable transports </li><ul><li>WebSocket, Long Polling and Callback Polling available </li></ul><li>Supports Cross-Origin servers
  91. 91. Extensible </li><ul><li>Many extensions already available </li></ul></ul></ul>
  92. 92. CometD Java <ul><li>The Java library features </li><ul><li>Highly scalable (the client is based on Jetty asynchronous HTTP Client)
  93. 93. Message batching
  94. 94. Lazy messages
  95. 95. A variety of listeners to be notified of relevant events in client and server
  96. 96. Data filters to automatically convert data
  97. 97. Extensions
  98. 98. SecurityPolicy </li></ul></ul>
  99. 99. Performance
  100. 100. DEMO
  101. 101. WebSocket Redux <ul><li>Slightly better maximal latency </li><ul><li>But don't run your pacemaker on it </li></ul><li>Slightly better data density </li><ul><li>If only that was a limitation! </li></ul><li>No help with hard problems </li><ul><li>Connection management
  102. 102. Handling Failures </li></ul><li>You still need a framework like CometD </li></ul>
  103. 103. References <ul><li>WebSocket </li><ul><li>http://www.w3.org/TR/websockets
  104. 104. http://www.ietf.org/id/draft-ietf-hybi-thewebsocketprotocol-01.txt </li></ul><li>CometD </li><ul><li>http://cometd.org </li></ul><li>Jetty </li><ul><li>http://eclipse.org/jetty </li></ul></ul>
  105. 105. Questions & Answers

×