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

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

18. Also known as the EventSource API
Server-Sent Events

19. Server-Sent Events : Introduction
12

20. Server-Sent Events : Introduction
1. Designed for Server to Client
communication
12

21. Server-Sent Events : Introduction
1. Designed for Server to Client
communication
2. Single long lived connection;
hence low latency
12

22. 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

23. Server-Sent Events : Use cases
• Activity feeds likeTwitter, Facebook,
StockTickers
• Analytics, Dashboards, Monitoring
• Chats, Instant Messaging *,
Collaborative editing like Google Docs
13

24. 14
Server-Sent Events :The Browser

25. Server-Sent Events :The Server
15

26. 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

27. 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

28. 1. ActionController::Live
2. Sinatra’s Streaming API
3. Faye
4. Cramp
5. Pusher
Server-Sent Events :App Integration
18

29. 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

30. EDGE
ActionController::Live
20

31. 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. 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

34. 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

35. Faye +Your App

36. 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

38. WebSockets
When Server-Sent Events are just not enough

39. WebSockets : Introduction
27

40. WebSockets : Introduction
1. Standalone Bidirectional protocol
27

41. WebSockets : Introduction
1. Standalone Bidirectional protocol
2. Message oriented, supports events by design
27

42. WebSockets : Introduction
1. Standalone Bidirectional protocol
2. Message oriented, supports events by design
3. Reliable text and binary transfers
27

43. WebSockets : Introduction
1. Standalone Bidirectional protocol
2. Message oriented, supports events by design
3. Reliable text and binary transfers
4. HTTP Compatible
27

44. 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

45. WebSockets :The Browser

46. WebSockets : Upgrade Handshake

47. 1. Faye +Your app
2. Cramp +Your app
3. websocket-rails
4. em-websocket, em-websocket-rails
5. Pusher
WebSocket
WebSockets :App Integration
31

48. 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

49. 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

50. 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

52. http://www.personal.psu.edu/afr3/blogs/siowfa13/yawning.jpg

54. Modern Day Kazaa, in an Iron Man Suit
WebRTC

55. WebRTC : Introduction
39
1. Peer-to-peer audio, video, and data sharing
between browsers
2. Standardised to a JavaScript API
3. Google Backed

56. WebRTC : Introduction
40
1. Acquire Audio andVideo data
2. Communicate Audio andVideo data
3. Communicate Arbitrary Application Data

57. WebRTC : Introduction
41
1. MediaStream
2. RTCPeerConnection
3. RTCDataChannel

58. WebRTC : Introduction
42
1. MediaStream
2. RTCPeerConnection
3. RTCDataChannel

59. WebRTC : Typical Workflow - Phase 1
43

60. 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

61. WebRTC : Typical Workflow - Phase 1
Incomplete
Code

62. WebRTC : Typical Workflow - Phase II
45

63. 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

64. WebRTC : Typical Workflow - Phase II

65. – Oscar Wilde
“Consistency is the last refuge of the unimaginative”

66. 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

67. 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

68. Further Reading

69. • HTML5Rocks ( it’s a website, not a collection of
rocks )
• http://studio.html5rocks.com/
• WebRTC official website
• Mozilla Developer Network
• http://simpl.info/
Websites

70. • Ilya Grigorik
• Sam Dutton
• Paul Irish
• Eric Bidelman
• Your own blog, one year from now
Blogs

71. • High Performance Browser Networking
• Getting Started with WebRTC
• HTML5: Up and Running
Books

72. Open Source
Opportunities

73. • 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 )

74. • 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

75. ThankYou !
57

76. Questions ?
58