1.
RSOCKET
THE FUTURE PROTOCOL
@OlehDokuka
/daniil-drobot

2.
MULTIPLAYER
PAC-MAN

3.
For Whom?
• NETWORKED APPS DEVELOPERS
• PERFORMANCE / REAL-TIME GEEKS
• REACTIVE ADOPTERS

4.
Oleh Dokuka
• WORKS FOR NETIFI
• REACTIVE GEEK
• REACTOR 3 CONTRIBUTOR
• BOOKS AUTHOR
• LOCAL COMMUNITY BUILDER
@OlehDokuka

5.
Daniil Drobot
• SOFTWARE DEV @ EQUINOX
• CS STUDENT @ KPI
/daniil-drobot

6.
Agenda
• DEFINE PROBLEM
• COMPARE PROTOCOLS
• HAVE FUN
• CHOOSE THE BEST PROTOCOL

7.
MULTIPLAYER
REQUIREMENTS

8.
Step 1: Setup

9.
Step 2: Location

10.
Step 3: Updates

11.
Step 3: Updates
100. Player 1
88. Player 3
80. Player 5
75. Player 2
68. Player 6
30. Player 4
7. Player 7
Scoreboard
+1+1+1+100+1

12.
ATTENTION!
This is still about microservices

13.
100. Player 1
88. Player 3
80. Player 5
75. Player 2
68. Player 6
30. Player 4
7. Player 7
Scoreboard
+1+1+1+100+1
Real Enterprise

14.
100. Player 1
88. Player 3
80. Player 5
75. Player 2
68. Player 6
30. Player 4
7. Player 7
Scoreboard ++++10+
Machine Learning

15.
100. Player 1
88. Player 3
80. Player 5
75. Player 2
68. Player 6
30. Player 4
7. Player 7
Scoreboard ++++10+
Machine Learning

16.
100. Player 1
88. Player 3
80. Player 5
75. Player 2
68. Player 6
30. Player 4
7. Player 7
Scoreboard ++++10+
Machine Learning
Ы

17.
TOOLKIT

18.
Back-end
• NODE.JS
• REACTOR-CORE-JS
• EXPRESS.JS
• TYPESCRIPT
• PROTOCOL BUFFER (a.k.a PROTOBUF)

19.
Front-end
• PHASER 3
• REACTOR-JS
• TYPESCRIPT
• PROTOCOL BUFFER (a.k.a PROTOBUF)

20.
But it is lagging

21.
DEMO
https://bit.ly/2G59PZY

22.
HTTP 1.x

23.
Why HTTP?
• PLAIN AND SIMPLE
• USED FOR MANY YEARS

24.
SOURCES

25.
Disadvantages
• MESSAGE OVERHEAD
• LOW PERFORMANCE
• INEFFICIENT RESOURCE USAGE
• COMMUNICATION RIGIDITY
• LACK RESILIENCE (NO BACKPRESSURE)

26.
Advantages
• SIMPLICITY IN DEVELOPMENT
• WIDE SUPPORT
• ALREADY IMPLEMENTED

27.
To Summarize
• SERVER PUSH
• PLAIN REQUEST-RESPONSE
• CLIENT-SIDE STREAMING
• SERVER-SIDE STREAMING

28.
To Summarize
• MACHINE LEARNING PIPE
• WHERE ANY COMPONENT CAN WORK SLOWER OR FASTER

29.
PROTOCOLS

30.
PROTOCOLS
• HTTP/1.x
• TCP
• HTTP/2
• ???

31.
PROTOCOLS
• HTTP/1.x
• WEBSOCKET
• HTTP/2
• ???

32.
COMPARISON

33.
• MAINTAINABILITY
• Frameworks
• Community/Adoption
• STABILITY
• Can work OK in unpredicted cases
• PERFORMANCE

34.
WEBSOCKET
/
HTTP2
WEBSOCKET

35.
Why WebSocket?
• NO OVERHEAD ~ TCP
• HIGH-PERFORMANCE

36.
Why NOT WebSocket?
• COMPLEX DEVELOPMENT
• REINVENT APPLICATION PROTOCOL

37.
Existing Solutions
• SOCKJS + STOMP
• SOCKET.IO

38.
SOCKET.IO

39.
DEMO
https://bit.ly/2CVcOC4

40.
QUICK SUMMUP
• DEV EXPERIENCE IS GOOD
• BUT LAGGING

41.
STABILITY

42.
100. Player 1
88. Player 3
80. Player 5
75. Player 2
68. Player 6
30. Player 4
7. Player 7
Scoreboard ++++10+
Ы
Scenario

43.
Scenario
Ы

44.
socket.emit("metrics", importantStatistic);
NETWORK I
socket.on("metrics", (importantStatistic) => {
…
});

45.
PURE PUSH

46.
socket.emit("metrics", importantStatistic);
NETWORK I
socket.on("metrics", (importantStatistic, ack) => {
…
ack(“done”)
});
socket.emit("metrics", importantStatistic);
NETWORK I
socket.on("metrics", (importantStatistic, ack) => {
…
ack(“done”)
});

47.
Results
Ы

48.
Advantages
• INTEGRATES WELL IN BROWSER
• COVERS ALL COMMUNICATION CASES
• USES ONLY ONE CONNECTION

49.
Disadvantages
• DEVELOPEMENT EXPERIENCE
• AVERAGE PERFORMANCE
• LACK OF RESILIENCE (HACKY BACKPRESURE)
• NO PROTOBUF SUPPORT

50.
We need Backpressure

51.
GRPC WAY

52.
Why GRPC?
• BUILT ON TOP OF HTTP/2
• GOOD DEVELOPMENT EXPERIENCE
• EASY TO BUILD API WITH PROTOBUF

53.
DEMO
https://bit.ly/2G2gVhu

54.
GRPC-WEB
CONNECTION 1
HTTP/2
HTTP/1.x
CONNECTION 1
CONNECTION 2

55.
GRPC-WEB
HTTP/2
HTTP/1.x
STATIC
CONNECTION 1
STATIC
CONNECTION 2

56.
Advantages
• SIMPLICITY IN DEVELOPMENT
• WIDE SUPPORT
• HIGH PERFORMANCE (for HTTP/2)
• EFFICIENT RESOURCE USAGE
• SUPPORTS BACKPRESSURE

57.
Disadvantages
• JUST A WRAPPER ON TOP OF HTTP/2
• AND GRPC-WEB T_T

58.
Netflix case study on
gRPC says that it lacks
backpressure
• https://bit.ly/2FUvHG3

59.
Summary
• Everything is either slow, hard to implement or lacks browser support
• Do you want to waste your time in searching how to solve the problems???

60.
RSOCKET WAY

61.
What is RSocket?

62.
What is RSocket?

63.
63
Binary

64.
64
Multiplexed

65.
STREAM BLUE
STREAM YELLOW
STREAM RED
65
Multiplexed

66.
66
Peer-to-peer
STREAM BLUE
STREAM RED

67.
67
Backpressure
Reactive-Streams
109

68.
68
Interaction modes
Multi

69.
69
Request-Response
Interaction modes
STREAM YELLOW

70.
70
Fire-and-Forget
Interaction modes
STREAM YELLOW

71.
71
Request-Stream
Interaction modes
STREAM YELLOW

72.
72
Stream-Stream
Interaction modes
STREAM YELLOW

73.
https://bit.ly/2TWxfEz
DEMO
https://goo.gl/X9bhio

74.
Advantages
• SIMPLICITY IN DEVELOPEMENT
• HIGH PERFORMANCE
• EFFICIENT RESOURCE USAGE
• WIDE COMMUNICATION MODEL
• HIGHLY-FLEXIBLE SETUP

75.
Disadvantages
• NOT WIDLY USED (FOR NOW)

76.
78
Maintainers

77.
Summary
STATS
PROTOCOLS
PERFORMANCE RELIABILITY
ADOPTION
/
COMUNITY
DEVELOPERS EXP
HTTP 1.X
👎 👎 👍 👍
SOCKET.IO
🤔 🤔 👍 👍
GRPC(HTTP/2)
👍 👍 👍/👎 👍 🤔
RSOCKET
👍 👍 😿 👍

78.
Summary
• EACH PROTOCOL HAS IT`S BENEFITS
• SOCKET.IO BETTER THEN PLAIN HTTP
• GRPC IS A BIT FASTER THAN RSOCKET
• RSOCKET FULLY COVERS OUR USE-CASE
• `CUZ REACTIVE IS ABOUT RESILIENCE

79.
Resources
• COMMUNITY -> https://community.netifi.com
• VIDEO CHANNEL -> https://bit.ly/2Fku9VC
• CLOUD NATIVE RSOCKET -> https://bit.ly/2JvDFdJ
@OlehDokuka
@netifi_inc
/daniil-drobot

80.
SOURCE PRESENTATION
@OlehDokuka
@netifi_inc
/daniil-drobot