1 / 13

Applying Database Replication to Multi-player Online Games

This paper explores the application of database replication in multiplayer online games (MOGs). It presents the motivation for using database replication, the unique requirements of MOGs, and the benefits associated with fault tolerance, scalability, and data consistency. The authors introduce a proof-of-concept game to experiment with various replication protocols, addressing challenges like transaction consistency and system performance. Ultimately, the study suggests a framework for applying database replication in MOGs to enhance gameplay experiences while ensuring efficient data management.

sanders-nestor
Télécharger la présentation

Applying Database Replication to Multi-player 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. Applying Database Replication to Multi-player Online Games Yi Lin Bettina Kemme Marta Patiño-Martínez Ricardo Jiménez-Peris Oct 30, 2006

  2. Outline • Motivation • Requirements of MOGs • Benefits of database replication • Introduction to database replication • A proof-of-concept game • Experiments

  3. What MOGs need? • Fault tolerance • Scalability … … Isolated game worlds

  4. What Database Replication does? • Providing fault tolerance • Scalability • Data consistency Read One DB Write All DBs • Most replication protocols are READ-ONE-WRITE-ALL

  5. Motivation • Why don’t we apply database replication to MOGs? • Unclear about • How to apply? • What are the challenges? • How is the performance? • Using a small game for proof-of-concept

  6. Introduction to Database Replication • Transaction • A transaction contains one or more read and/or write requests • Atomic. • Commit: all requests successful. • Abort: none of writes will take effect • Consistent • Isolated • Durable • Challenge of database replication: • How to guarantee data consistency in terms of transaction?

  7. w(x) w(x) x x x x x x Database Replication: challenge • Replication protocols • Keep copies consistent • Isolate concurrent transactions • Ideally: • The whole system behaves as if there is one database Replica control

  8. commit commit w(x) w(x) r(x) r(x) T1 validation succeed T2 validation fail Extract writeset apply ws, commit Extract writeset abort commit x x x x JDBC JDBC SEQ Replication Protocol T1 T2 Sequencer

  9. Lazy Primary Limitation: Need to know if a transaction is read-only or not in advance Symmetric Limitation: Need to know all operations in a transaction in advance SRCA-REP Need support of group communication systems We build a middleware platform, MiddleSIR, to accommodate all these protocols. JDBC JDBC Other replication protocols Comm Mgr Comm Mgr Txn Mgr Txn Mgr Conn Mgr Conn Mgr

  10. Modeling based on transactions E.g., two players might type same string concurrently. Model: Typing a string as one transaction, while typing a character as an operation E.g., All players see the same game interfaces Model: Periodically reading data (e.g., strings, bullets, scores) from database as one transaction. A proof-of-concept game

  11. Experiments in WANs, Scalability

  12. Experiments in WANs, 4 servers, Write transactions

  13. Conclusion • Propose a new approach of system supports for MOGs • Applying database replication to MOGs for fault tolerance, scalability, performance, ease of concurrency control • Use a small game for proof-of-concept • Data consistency is guaranteed • Response time is good, even in WANs. • Scalability is not good. • Read-one / Write-All replication only scales if the percentage of reads is very high. • Future work: use partial replication (Write only a few servers)

More Related