Upload
swanand-pagnis
View
1.630
Download
2
Embed Size (px)
DESCRIPTION
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
Citation preview
Let’s get real (time): Server-Sent Events, WebSockets and WebRTC for
the soulA guided tour of modern browser networking
Swanand Pagnis [email protected]
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
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
Yours truly• Bangalore RUG, Mysore RUG, Garden City
RubyConf
• Hack code at Simplero for a living
• Twitter @_swanand
• Github @swanandp
What’s in store for us
1. Why bother ?
What’s in store for us
1. Why bother ?
2. The Zen of Real Time Communication
What’s in store for us
1. Why bother ?
2. The Zen of Real Time Communication
3. Concepts and app Integration with:
What’s in store for us
1. Why bother ?
2. The Zen of Real Time Communication
3. Concepts and app Integration with:
1. SSE
What’s in store for us
1. Why bother ?
2. The Zen of Real Time Communication
3. Concepts and app Integration with:
1. SSE
2. WebSockets
What’s in store for us
1. Why bother ?
2. The Zen of Real Time Communication
3. Concepts and app Integration with:
1. SSE
2. WebSockets
3. WebRTC
What’s in store for us
1. Why bother ?
2. The Zen of Real Time 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
Problems with traditional approaches
Why Bother ?
1. Poor performance because of high latency
2. Neither truly async nor truly real time, often limited to Text transfer only
3. Either additional complexity and inconvenience or hacky methods
���7
Problems with traditional approaches
The Zen of Real Time Communication
• Escape from Request-Response cycle
• Do not be bound to HTTP
• It may or may not always REST
Also known as the EventSource API
Server-Sent Events
Server-Sent Events : Introduction
���12
Server-Sent Events : Introduction
1. Designed for Server to Client communication
���12
Server-Sent Events : Introduction
1. Designed for Server to Client communication
2. Single long lived connection; hence low latency
���12
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
Server-Sent Events : Use cases
• Activity feeds like Twitter, Facebook, Stock Tickers
• Analytics, Dashboards, Monitoring
• Chats, Instant Messaging *, Collaborative editing like Google Docs
���13
���14
Server-Sent Events : The Browser
Server-Sent Events : The Server
���15
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
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 or Thin )
3. Long running connection means long running
process on the server
Server-Sent Events : App Integration
���17
1. ActionController ::Live
2. Sinatra’s Streaming API
3. Faye
4. Cramp
5. Pusher
Server-Sent Events : App Integration
���18
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
EDGE
ActionController ::Live
���20
Sinatra’s Streaming API
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
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
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
Faye + Your App
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 approachRant
���24
WebSocketsWhen Server-Sent Events are just not enough
WebSockets : Introduction
���27
WebSockets : Introduction
1. Standalone Bidirectional protocol
���27
WebSockets : Introduction
1. Standalone Bidirectional protocol
2. Message oriented, supports events by design
���27
WebSockets : Introduction
1. Standalone Bidirectional protocol
2. Message oriented, supports events by design
3. Reliable text and binary transfers
���27
WebSockets : Introduction
1. Standalone Bidirectional protocol
2. Message oriented, supports events by design
3. Reliable text and binary transfers
4. HTTP Compatible
���27
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
WebSockets : The Browser
WebSockets : Upgrade Handshake
1. Faye + Your app
2. Cramp + Your app
3. websocket-rails
4. em-websocket, em-websocket-rails
5. Pusher
WebSocket
WebSockets : App Integration
���31
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
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
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
http://www.personal.psu.edu/afr3/blogs/siowfa13/yawning.jpg
Modern Day Kazaa, in an Iron Man Suit
WebRTC
WebRTC : Introduction
���39
1. Peer-to-peer audio, video, and data sharing between browsers
2. Standardised to a JavaScript API
3. Google Backed
WebRTC : Introduction
���40
1. Acquire Audio and Video data
2. Communicate Audio and Video data
3. Communicate Arbitrary Application Data
WebRTC : Introduction
���41
1. MediaStream
2. RTCPeerConnection
3. RTCDataChannel
WebRTC : Introduction
���42
1. MediaStream
2. RTCPeerConnection
3. RTCDataChannel
WebRTC : Typical Workflow - Phase 1
���43
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
WebRTC : Typical Workflow - Phase 1
Incomplete
Code
WebRTC : Typical Workflow - Phase II
���45
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
WebRTC : Typical Workflow - Phase II
– Oscar Wilde
“Consistency is the last refuge of the unimaginative”
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
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
Further Reading
• HTML5Rocks ( it’s a website, not a collection of rocks )
• http://studio.html5rocks.com/
• WebRTC official website
• Mozilla Developer Network
• http://simpl.info/
Websites
• Ilya Grigorik
• Sam Dutton
• Paul Irish
• Eric Bidelman
• Your own blog, one year from now
Blogs
• High Performance Browser Networking
• Getting Started with WebRTC
• HTML5: Up and Running
Books
Open Source Opportunities
• 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 )
• 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
Thank You !
���57
Questions ?
���58