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