12 feb 2014 kl. 17:06 skrev Justin du coeur: > In general, I'd say that makes sense -- although as Roland observes, it's not > obvious that the front-end pieces add much value if this is just for testing > and learning Akka. > > One question to think about is how big each "Game" is. If you're talking > about a server for small-scale game instances (eg, 2-20 players per game), > then this design makes sense. OTOH, if you're aiming at something more > massively-multiplayer, with large numbers of Players per Game, then the Game > Actor will become a bottleneck. If that's the case, then I'd recommend > thinking about how to decompose the Game into a large number of cooperating > Actors, each of which owns a distinct chunk of the game's state. (Eg, an > Actor per room, or something like that -- basically, find a sensible division > of the state.) > > Also, you *may* want a separate Actor for the database operations, to prevent > the DB from blocking the flow of messages through the Game. This is a very > common issue, since most DB interfaces are blocking: it's important to keep > those blocking operations isolated from the rest of the data flow. > > The architecture for my app is fairly similar: each browser window > corresponds to a UserSession Actor. These are each talking to a Space Actor, > where a Space keeps track of a big block of state, providing that state to a > typically-modest number of attached UserSessions. Each Space Actor in turns > owns a SpaceDB Actor, which it offloads all DB updates to, so that those > updates don't block state queries from the UserSessions. This division of > labor keeps state queries lightning-fast, since the DB is out of the way. > > This is a good example of how to think in Akka: you're looking for ways to > slice-and-dice your state such that each Actor "owns" a distinct chunk of it, > and the expected data flow through that state is reasonably modest...
Well spoken, Justin! Regards, Roland > > > On Mon, Feb 10, 2014 at 9:56 PM, Tagir Magomedov <[email protected]> > wrote: > Hello everyone. I guess it's one of those "should I use Akka for this" posts. > > I'm completely new to distributed application design and am trying to do this > test application to get some understanding on how it all works together. Thus > I would appreciate any feedback on the following application design. > > Problem: > > Design a turn-based multiplayer game. > > Possible implementation: > > I'm thinking of the following high-level implementation/workflow: > > Client (Mobile/Web/etc) <-> SignalR ASP MVC website <-> Azure/AWS MQ <-> Akka > actors <-> DB > > Each connected client will have a corresponding Player actor in Akka backend. > > All requests/responses for a client would go through SignalR ASP frontend and > delegated through message queue to appropriate backend actors. > > All moves/state queries to the game would be made by those Player actors to > corresponding Gameactor in backend which will handle updating game state in > DB. > > Question: > > Does that design make sense? Is it a correct use-case for Akka? > > > Thanks, > Tagir. > > p.s. > Copied from: > http://stackoverflow.com/questions/21691169/asp-net-to-akka-through-azure-aws-message-queue > > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: http://akka.io/faq/ > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: http://akka.io/faq/ > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/groups/opt_out. Dr. Roland Kuhn Akka Tech Lead Typesafe – Reactive apps on the JVM. twitter: @rolandkuhn -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/groups/opt_out.
