Your SlideShare is downloading. ×
Let's Get Real (time): Server-Sent Events, WebSockets and WebRTC for the soul
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Let's Get Real (time): Server-Sent Events, WebSockets and WebRTC for the soul

1,438
views

Published on

A guided tour of modern browser networking. We'll look at SSEs, WebSockets and WebRTC and see how to integrate them in your Ruby based app. …

A guided tour of modern browser networking. We'll look at SSEs, WebSockets and WebRTC and see how to integrate them in your Ruby based app.

( This slides accompanied my talk at RubyConf India, 2014 0

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,438
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
15
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Let’s get real (time): Server-Sent Events,WebSockets and WebRTC for the soul A guided tour of modern browser networking Swanand Pagnis swanand@pagnis.in
  • 2. Yours truly • Originally from Krypton, often mistaken as the last survivor • Sent to earth in a spaceship while still a baby • A few useful superpowers • Suspiciously good at hiding in plain sight
  • 3. Yours truly • Originally from Krypton, often mistaken as the last survivor • Sent to earth in a spaceship while still a baby • A few useful superpowers • Suspiciously good at hiding in plain sight
  • 4. Yours truly • Bangalore RUG, Mysore RUG, Garden City RubyConf • Hack code at Simplero for a living • Twitter @_swanand • Github @swanandp
  • 5. What’s in store for us
  • 6. 1. Why bother ? What’s in store for us
  • 7. 1. Why bother ? 2. The Zen of RealTime Communication What’s in store for us
  • 8. 1. Why bother ? 2. The Zen of RealTime Communication 3. Concepts and app Integration with: What’s in store for us
  • 9. 1. Why bother ? 2. The Zen of RealTime Communication 3. Concepts and app Integration with: 1. SSE What’s in store for us
  • 10. 1. Why bother ? 2. The Zen of RealTime Communication 3. Concepts and app Integration with: 1. SSE 2. WebSockets What’s in store for us
  • 11. 1. Why bother ? 2. The Zen of RealTime Communication 3. Concepts and app Integration with: 1. SSE 2. WebSockets 3. WebRTC What’s in store for us
  • 12. 1. Why bother ? 2. The Zen of RealTime Communication 3. Concepts and app Integration with: 1. SSE 2. WebSockets 3. WebRTC 4. Further reading and open source opportunities What’s in store for us
  • 13. Problems with traditional approaches Why Bother ?
  • 14. 1. Poor performance because of high latency 2. Neither truly async nor truly real time, often limited toText transfer only 3. Either additional complexity and inconvenience or hacky methods 7
  • 15. Problems with traditional approaches The Zen of RealTime Communication
  • 16. • Escape from Request-Response cycle • Do not be bound to HTTP • It may or may not always REST
  • 17. Also known as the EventSource API Server-Sent Events
  • 18. Server-Sent Events : Introduction 12
  • 19. Server-Sent Events : Introduction 1. Designed for Server to Client communication 12
  • 20. Server-Sent Events : Introduction 1. Designed for Server to Client communication 2. Single long lived connection; hence low latency 12
  • 21. Server-Sent Events : Introduction 1. Designed for Server to Client communication 2. Single long lived connection; hence low latency 3. Simple cross browser API 12
  • 22. Server-Sent Events : Use cases • Activity feeds likeTwitter, Facebook, StockTickers • Analytics, Dashboards, Monitoring • Chats, Instant Messaging *, Collaborative editing like Google Docs 13
  • 23. 14 Server-Sent Events :The Browser
  • 24. Server-Sent Events :The Server 15
  • 25. Server-Sent Events : Summary 1. Simple Protocol that builds on top of HTTP 2. Truly async 3. Perfect for “notifying” the client 4. Great cross browser support, but no binary support 16
  • 26. 1. Traditional Rack based app are a slight misfit because of response buffering ( Remember our first Zen ? ) 2. Evented architecture works in our favour (Think of EM::Deferrable orThin ) 3. Long running connection means long running process on the server Server-Sent Events :App Integration 17
  • 27. 1. ActionController::Live 2. Sinatra’s Streaming API 3. Faye 4. Cramp 5. Pusher Server-Sent Events :App Integration 18
  • 28. 1. Streaming and SSE support baked right into Rails ( > 4.0 ) 2. You keep the full context ( current_user etc ) 3. Integration friendly, almost a drop-in feature into existing Rails apps ActionController::Live 19
  • 29. EDGE ActionController::Live 20
  • 30. Sinatra’s Streaming API
  • 31. 1. You only need Sinatra, Thin and some Javascript 2. So simple, you will cry with happiness 3. No app context 4. So simple, you will beg for more features Sinatra’s Streaming API
  • 32. 1. You only need Sinatra, Thin and some Javascript 2. So simple, you will cry with happiness 3. No app context 4. So simple, you will beg for more features Sinatra’s Streaming API
  • 33. 1. Running a separate process that acts as a server, and your server and client act as clients to this server 2. Pub / sub model, drop-in integration with your app 3. Graceful degradation 4. No app context Faye +Your App 22
  • 34. Faye +Your App
  • 35. Apps that have more traditional components than real time 1. Use a separate process / service / app for the real time part ( e.g. Faye or Pusher or BYOT ) 2. Use existing infrastructure for non real time aspects of the app Recommended approach Rant 24
  • 36. WebSockets When Server-Sent Events are just not enough
  • 37. WebSockets : Introduction 27
  • 38. WebSockets : Introduction 1. Standalone Bidirectional protocol 27
  • 39. WebSockets : Introduction 1. Standalone Bidirectional protocol 2. Message oriented, supports events by design 27
  • 40. WebSockets : Introduction 1. Standalone Bidirectional protocol 2. Message oriented, supports events by design 3. Reliable text and binary transfers 27
  • 41. WebSockets : Introduction 1. Standalone Bidirectional protocol 2. Message oriented, supports events by design 3. Reliable text and binary transfers 4. HTTP Compatible 27
  • 42. 1. All the use cases of SSEs, plus: 2. Multiplayer games, Multi-media chat * 3. Remote pair programming, Online contests, Live interviews, Screen sharing, Remote Desktop etc. WebSockets : Use Cases 28
  • 43. WebSockets :The Browser
  • 44. WebSockets : Upgrade Handshake
  • 45. 1. Faye +Your app 2. Cramp +Your app 3. websocket-rails 4. em-websocket, em-websocket-rails 5. Pusher WebSocket WebSockets :App Integration 31
  • 46. Cramp +Your App 32 1. Run Cramp as a standalone app 2. Provides an app like functionality around RTC 3. Think of it as Rails for real time apps 4. No drop-in integration with existing app
  • 47. Cramp +Your App 33 1. Controller becomes Action 2. Action becomes Event, triggered with on_data 3. params become data 4. Connection open by default
  • 48. Recommended approach 34 Apps that are heavily real time 1. Use Cramp to build a stand alone app 2. Be an API consumer for your other app for any additional functionality Rant
  • 49. http://www.personal.psu.edu/afr3/blogs/siowfa13/yawning.jpg
  • 50. Modern Day Kazaa, in an Iron Man Suit WebRTC
  • 51. WebRTC : Introduction 39 1. Peer-to-peer audio, video, and data sharing between browsers 2. Standardised to a JavaScript API 3. Google Backed
  • 52. WebRTC : Introduction 40 1. Acquire Audio andVideo data 2. Communicate Audio andVideo data 3. Communicate Arbitrary Application Data
  • 53. WebRTC : Introduction 41 1. MediaStream 2. RTCPeerConnection 3. RTCDataChannel
  • 54. WebRTC : Introduction 42 1. MediaStream 2. RTCPeerConnection 3. RTCDataChannel
  • 55. WebRTC : Typical Workflow - Phase 1 43
  • 56. WebRTC : Typical Workflow - Phase 1 43 1. Connect to the Signalling Server, let it know: 1. Your Identity ( STUN ) 2. How to reach you ( ICE Candidate ) 2. Once a peer is detected by the server, it in turns gives you the above info 3. At this point, we are ready for a P2P connection
  • 57. WebRTC : Typical Workflow - Phase 1 Incomplete Code
  • 58. WebRTC : Typical Workflow - Phase II 45
  • 59. WebRTC : Typical Workflow - Phase II 45 1. Create a stream to send and receive binary data 2. Create a channel to send and receive text data 3. Actually send and receive data
  • 60. WebRTC : Typical Workflow - Phase II
  • 61. – Oscar Wilde “Consistency is the last refuge of the unimaginative”
  • 62. WebRTC : Use Cases 48 1. Motherlode of Skype clones, free and open source! 2. Screen sharing, remote pairing, multiplayer games, browser based torrents, Live MOOCs 3. In reality, this is limited mostly by our imagination and browser’s computing abilities
  • 63. WebRTC : Dive in 49 1. Use any of the JavaScript libs / SDKs : 1. Open Source: SimpleWebRTC, webRTC.io, PeerJS, EasyRTC, ShareFest 2. Commercial: PubNub WebRTC SDK 2. Signalling service example in Ruby 1. OSS : github.com/palavatv/palava-machine
  • 64. Further Reading
  • 65. • HTML5Rocks ( it’s a website, not a collection of rocks ) • http://studio.html5rocks.com/ • WebRTC official website • Mozilla Developer Network • http://simpl.info/ Websites
  • 66. • Ilya Grigorik • Sam Dutton • Paul Irish • Eric Bidelman • Your own blog, one year from now Blogs
  • 67. • High Performance Browser Networking • Getting Started with WebRTC • HTML5: Up and Running Books
  • 68. Open Source Opportunities
  • 69. • Help out Faye, Cramp and other libraries mentioned so far • Open source all your throw-away code written during learning ( Mine is on Github ) • Async-proof versions of commonly needed ruby gems ( e.g. github.com/rkh/async-rack )
  • 70. • Helper Libraries for Cramp, e.g. • To easily build simple board games • To write calendar based real time apps • Augment the testing libraries to test real time stuff • Write and make your benchmarks available
  • 71. ThankYou ! 57
  • 72. Questions ? 58