Hi Arno, What I was considering is the idea that a user is idempotent, but may find itself associated across the cluster to a “world geography”. One shard aggregates users, one shard aggregates geographies. In the analogy, the user shard is the HLR, the geography shard is the VLR. It’s not exact, of course. Communicating between the two is managed by key through the shard region controllers. So the user would maintain the key of the geography that it is currently in, and likewise the geography would maintain a list of the keys for the users that are in it.
>From a perspective of locality, it does not change that the user will be >instantiated in the node where the shard is “balanced” to. As I re-read your >OP, I think I mis-considered your goals. What if you kept the shard for the geographies and removed it for the users, keeping the latter persistent all the same. Then spread the persistence configuration for users across the cluster (I use ZK for this). The user could then be restored as a child of the geography by the sharded geography actor, on that same node. A basic implementation would require that the user actor was on one node at a time. You might want some security against the user actor being started in multiple geographies. It might be completely reasonable for the user actor to be multiply available like that, maybe by wiring distributed PubSub into the persistent user actor event loop. I haven’t thought though the scalability or performance of this, just offering ideas. Brian > On Dec 10, 2017, at 3:44 PM, Arno Haase <[email protected]> > wrote: > > Brian, thanks for the pointer. > > I just googled HLR, and the idea I took away is that there is a master > record on a fixed server node (the HLR) with a redundant copy on a > topologically close server node (the VLR) which is updated periodically. > > This kind of architecture does not look attractive for my problem, but I > may have missed some key point of HLR / VLR. > > But player data changes frequently (several times per second), and I > want to avoid round trips between servers to save bandwidth and reduce > latency. I am looking for a solution that actually moves / migrates the > player actor to a different server node according to where in the game > the player's character has currently moved. > > Something like sharding with the same entity moving from shard to shard > over time (and yes, I know that is not how sharding works ;-) ) > > - Arno > > > Am 10.12.2017 um 19:14 schrieb Brian Topping: >> I would check out the concept of the "Home Location Register" in the >> realm of cellular telephony. >> >> On Sunday, December 10, 2017 at 3:03:33 AM UTC-7, Arno Haase wrote: >> >> I am thinking about how to build a massively parallel online game on >> top >> of Akka cluster. The game is based on a huge two dimensional "world" >> through which players can move. > > -- >>>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>>> Check the FAQ: >>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to a topic in the Google > Groups "Akka User List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/akka-user/_ogMHnVWm78/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> 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 https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Message signed with OpenPGP
