Newbie Spellweaver
- Joined
- Aug 6, 2014
- Messages
- 56
- Reaction score
- 42
Personally I think it is a good thing to split up the servers and the clients, because in this way it would be impossible for the client to affect the server.
So it really just is a piece of fault tolerance.
Though this is also how the Akka documentation advised on how to use the TCP system so I sticked with it.
So basically the server Actors will try to restart when something occurred they could not recover from while the client Actors will simply be killed to prevent anything from escalating.
I wanted to write a MapleStory server in Erlang but never got around to it, so I'm looking forward to seeing your progress because it is naturally going to be architecturally similar. Making each client an actor seems like the right thing to do. With that said, here are some considerations:
Don't really get what you mean by client affecting the server, but the main benefit I see in making each client an actor is to have the power to persist client state even if a server fails. You can look into making each client supervise its server actor, so if a server fails then the character data can be persisted and the client session can be automatically migrated to a functioning server. Akka has some cool health checking functionality, but I don't know if it's possible to have a many-to-one supervision scheme, or if it's even necessary - maybe there's a simpler way. I'm not overly familiar with Akka.
Also I looked through your code a little bit (I like it when things are on Github) and it seems like you never keep characters in memory? Every time a user gets its character it re-constructs one from the database. If I'm not wrong, then perhaps you should look into changing that.
It seems like you have two actors per player (one as the Client, one unnamed representing the raw tcp connection between player and server), but I guess that doesn't really matter.
Like others have said, you really should use pattern matching on Options and similar things instead of for loops though, it's more readable and is considered good practice.
Have you thought about how you are going to implement cross-server messages? Right now I don't think you keep track of all clients in the server, so you should probably think about how you would implement a super megaphone (or buddy/guild chat, etc) because that's probably a design decision that needs to be made early on.
It seems like this is where there is added complexity by making each client its actor.
Last edited: