1 / 27

Dynamic Server Selection for Large Scale Interactive Online Games

Dynamic Server Selection for Large Scale Interactive Online Games. Bong-Jun Ko, Dan Rubenstein (Columbia U.) Kang-Won Lee, Seraphin Calo (IBM T. J. Watson). Talk Outline. Motivations Synchronization Delay Model Problem Statement Server Selection Algorithms Performance Evaluation

germaine-vega
Download Presentation

Dynamic Server Selection for Large Scale Interactive Online Games

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Dynamic Server Selection for Large Scale Interactive Online Games Bong-Jun Ko, Dan Rubenstein (Columbia U.) Kang-Won Lee, Seraphin Calo (IBM T. J. Watson)

  2. Talk Outline • Motivations • Synchronization Delay Model • Problem Statement • Server Selection Algorithms • Performance Evaluation • Conclusions

  3. Motivation • Large-scale online games (e.g. MMOG) start toincorporate real-time interactive features. • Game service providers must satisfy tight delay requirements and large scale user group at the same time. • To achieve scalability and efficient resource sharing, it is important to reduce game server resources used.

  4. Our Goals • Develop a synchronization delay model for interactive online applications in mirrored-server architecture • Design a distributed server selection algorithm to minimize resource consumption while meeting the overall delay constraints.

  5. Action Action State State Synchronization Delay in Online Games • Two different types of synchronization delay • Upstream (Action Delivery) delay • Downstream (State Update) delay

  6. Server Clients Mirrored-Server Architecture • S (set of available servers) and C (set of clients) • A: CS (server allocationthat maps each client in C to a server in S)

  7. Sync-delay in Mirrored-Servers • DUP(i, k) : Upstream Delay from client i to server k • DDOWN(k, i) : Downstream Delay at server k to client i • DSYNC(A) : Overall sync-delay under allocation A DSYNC(A) = maxk{maxi DUP(i, k) + maxi DDOWN(k, i)}

  8. Problem statement • Find an allocation Amin that minimizes the number of allocated servers,|A(C)|, subject to • DSYNC(A) , • |A(C)|  1, and • C(si)  Ci(C(si) : the capacity of server si )

  9. 5 3 1 1 1 3 1 5 Sync-delay revisited: Example C1 S1 S2 S3 C2

  10. Sync-delay revisited: Example C1 5 3 1 1 1 S1 S2 S3 3 1 5 C2 DSYNC = 3+3 = 6

  11. Sync-delay revisited: Example C1 5 3 1 1 1 S1 S2 S3 3 1 5 C2 DSYNC = 5+5 = 10

  12. Sync-delay revisited: Example C1 5 3 1 1 1 S1 S2 S3 3 1 5 C2 DSYNC = 3+1 = 4

  13. Observations • Connecting clients to a server further than the ‘center’ doesn’t reduce the overall delay. • Allocating ‘edge’ servers generally decreases the delay, but increases the number of servers.

  14. Server Selection Algorithm:Zoom-In-Zoom-Out(ZIZO) • Find the “core” server that minimizes the maximum distance from the client. • Connect each client to the closest server. • For each client, probe a server “closer” to the core serve. If sync-delay is still within bound, migrate the client to that server. Repeat until no client can move. • For each client, probe an allocated server “further” from the core server, and migrate if the sync-delay is within bound. Repeat until no client can move.

  15. Why Zoom-Out?

  16. Why Zoom-Out?

  17. Why Zoom-Out?

  18. Why Zoom-Out?

  19. Why Zoom-Out?

  20. Variations • Selecting next server to probe : • By searching next closest server toward core server (Sr) • By moving up/down along a Core-Based Tree in the server network (Tr) • Migrating clients • Client-based : move each client one at a time (C) • Server-based : move all clients attached to a server simultaneously (S)

  21. Simulation setup • A transit-stub network of 5,000 nodes generated by a topology generator (100 AS x 50 nodes/AS) • |S| servers selected at random and form a low-latency network among them with average degree 5. (|S|=100, 200) • |C| clients selected at random, each connected to the closest server initially. (|C|=50, 100) • Sync-delay bound () : 20 ~ 50 msec.

  22. Greedy Server Selection Algorithm • A centralized algorithm • Keep adding servers until the sync-delay becomes within the bound. • When adding a server, add the one that minimizes the overall sync-delay.

  23. Result : Unbounded server capacity |S|= 100, |C| = 50, C(s) = 

  24. ZINS(Zoom-In-’N-Stop) vs ZIZO |S|= 100, |C| = 50, C(s) = 

  25. Result : Bounded server capacity |S|= 100, |C| = 50, C(s) = 10

  26. Conclusions • We presented a novel synchronization delay model for interactive online games. • We proposed a set of simple and effective distributed heuristics that efficiently utilize server resource. • Future Work • Complexity analysis of the problem • Efficient core-selection method • Play PlanetSide !

More Related