Multiplayer Pac-Man with RSocket
summary
Compares HTTP, WebSocket and gRPC by actually building a multiplayer Pac‑Man using Reactor, Protobuf, Phaser and RSocket; shows HTTP floods requests and lags, gRPC’s Java backpressure races and spikes memory, while RSocket runs the game smoothly with real backpressure over network, single multiplexed connection, binary messages and resumeable streams; demos show controlled request(n) delivery from browser, stable throughput and lower latency; warns of limited docs and adoption despite clear gains for cloud‑native, low‑latency multiplayer.
AI-written summary · about
chapters (33)
- 0:00Start
- 1:16Agenda
- 3:18MULTIPLAYER
- 4:13Step 2: Location
- 4:38Step 3: Updates
- 5:58Real Enterprise
- 7:53To Summarize
- 8:29Back-end
- 9:32Front-end
- 9:47Why HTTP?
- 12:19Why NOT HTTP?
- 13:34HTTP FLOW CONTROL
- 15:37REACTIVE-STREAMS
- 16:07PROTOCOLS
- 17:10MAINTAINABILITY
- 18:10Why WebSocket?
- 18:34Why NOT WebSocket?
- 19:16Existing Solutions
- 19:55Why not STOM/socket.io
- 21:41Why gRPC?
- 25:19GRPC-WEB
- 28:20WHAT IF
- 28:37Scenario
- 30:56CloudNative JVM Setup
- 32:53Netflix case study on gRPC
- 37:36Communication
- 38:11Notable Features
- 48:13RPC API
- 48:43SPRING-MESSAGING
- 50:36Disadvantages
- 51:04Maintainers
- 51:27Summary
- 51:57Resources
related talks
01h 01mThe RSocket Protocol — The Future of Reactive Applications
25mWhat the Web can Learn from Video Game Networking
40mMultiplayer Gaming Architecture and Design
47mReliving the History of Multiplayer Games
24mHow We Built Protosockets to Go Beyond HTTP and gRPC
42mRSocket - Future Reactive Application Protocol
01h 52m100% Fast and Resilient Microservice with RSocket
45mOnline Games, But How Come They Don't Lag?