Sync-MS: Synchronized Messaging Service for Real-Time Multi-Player Distributed Games

1. Sync-MS: Synchronized Messaging Service for Real-Time Multi-PlayerDistributed Games By Yow-Jian Lin, Katherine Guo and Sanjoy Paul Presented by Greg Kempe

2. Overview • Background • Assumptions • Sync-MS description • Performance • Discussion

3. Background • Realtime online multi-player games becoming increasingly popular • Geographically distributed participants • Different network characteristics • Especially: different levels of delay • Lead to fairness issues • Players with low delay can react faster • Some techniques can give the advantage to high-delay players!

4. Assumptions • Client-server model • Only indirect communication between clients, via server • Timeliness is key, so UDP is preferred • All clocks are synchronised (eg. NTP) • Basic scenario: • Client sends action message • Server processes actions, sends periodic state update message to clients

5. Two fairness issues • Uneven update message delivery • Players with low delay get updates first, can react sooner • Action messages processed out-of-order • Players with low delay can react faster

6. Sync-MS • Key idea: trade higher delay at some players, for greater global fairness • Sync-MS: game-independent service to solve fairness issues • Architecture • One SMS (server) between server and players • SMC (client) between each player and SMS

7. Components • Sync-out: solves uneven state update message delivery • Sync-in: solves out-of-order action messages

8. Sync-out • Deliver update messages to all players at the same time • Mark update to be delivered at time T=t+D • t is “now” • D is greater than the longest delay from the server to any client • SMC’s receive message and wait until T before passing it on to the application • “Late” messages can be discarded

9. Sync-in • Deliver action messages to game server in a fair manner • Server receives action messages, possibly out of order • Places actions in queue, oldest at head • Waits for some period W, in case other actions arrive, then gives head of queue to application • “Late” messages can be discarded • How is W determined?

10. Sync-in

11. Waiting for actions • Three ways of finding W • MaxWait: max of network delays from all clients to server • Gives actions occurring before current head time to arrive • Can slow down everyone’s response time to slowest client • SelectWait: max of network delays from only those clients that could have sent actions • Requires time between actions for each client • Can give best fairness with least delay

12. Waiting for actions • TossWait: add random unfairness to get better responsiveness • W ranges from (effectively) 0 to WMaxWait, chosen randomly, weighted towards WMaxWait • Is usually fair, sometimes a little unfair to improve responsiveness • A really lagged player doesn’t hinder everyone else • Weighting is based on delay percentiles, allows for tweaking

13. Performance • Simulated 10 players, 1 server in Matlab • ±14 minutes, 4000+ action messages per player • Mean delay of 4–30ms, distributed exponentially • Increases with player ID • Performance metrics • Messages behind: delivered late, after they should have been • Messages ahead:delivered early, ahead of their true position (i.e. cheated some other message and forced it to be behind)

14. Messages behind delay

15. Messages ahead delay

16. Average response time

17. References • A Fair Message Exchange Framework for Distributed Multi-Player Games (next paper): removed synchronised clocks requirement • First author’s website: • http://www.bell-labs.com/user/kguo/

18. Discussion • Is “fairness” really fair? • Delay times: is 100ms really good enough? • MiMaze did similar things with buckets