Load Balancing questions

mindlube

use case: I am writing my own Photon app, by subclassing ApplicationBase. My game is asynchonous turn-based, with multiple matches, and is inheritently not Room based. So I've shied away from using Lite at all. I've got the Photon API basics down, and using the Unity .NET client works fine so far with my bare-bones photon app. Now considering load balancing though.

Q1) I see LoadBalancing solution has a reference to Lite. That's not good... How tightly coupled is that to Lite? On the promising side, I see a generic parameter in LoadBalancer.cs :
LoadBalancer<TServer>
How hard is it going to be for me to get Load Balancing working with a non-Lite application? any pointers or suggestions?

Q2) On the .NET client side, is the load balancing completely transparent code-wise? I mean can I implement load balancing later on at some point, and as long as the Load Balancer is running on the same host name and port # as what my Instance1 is now running on, will that work OK without any client side code changes?
Hope those questions make sense

dreamora

Q1) load balancing is no 'general solution'. Its an extension of Lite and getting it anywhere else will be very hard as it bases on the Lite assumptions pretty much everywhere.

Q2) Nope likely not. Loadbalancing with its reconnecting etc is not exactly the same as lite. But its only a limited amount of work to get it going on the client side. But if you try to port something else to make use of load balancing it does not matter cause then you will need to write your own client side for it anyway more or less

Tobias

Can you elaborate a bit on what you need to achieve? Might help us give feedback.
My thought were: It's not room based, so maybe just don't use Rooms within Lite. The peers can execute operations as well, so not all has to be piped into a room. It's a matter of how players will interact. Do they see each other, interact, is it competitive, persistent?

A1) While Loadbalancing is not a general solution and tightly interacting with the Room concept, the balancing of machines does not rely on it. You will need to replace the mechanism to forward players to specific game servers, cause you can't send them to one or the other, based on rooms.

A2) It's not completely transparent. We use certain events and implemented a state machine client side to move from master to game server and back. It's fully visible for you and open for modifications.

mindlube

Thanks Tobias, it's a dominos game = turn based, casual, social, and players are encouraged to have multiple matches/games going on and to switch into another game when it's their turn.

Now that I've got the basics working, perhaps I should see if I can fit it into the Lite paradigm. I can see benefits of that especially with loadbalancing and maybe other features such as the caching.

It could be thought of each game == a room. But with custom coding for these main requirements which are different than Lite:
- send custom events to peers when it's your turn in games/room which you are not currently joined.
- save game state when all players leave room (persistent rooms)
- i'll add chat too, within a room only

However I really like the *simplicity* of just subclassing ApplicationBase and adding only the required functionality. Hmmm.... :idea:

Kaiserludi

mindlube wrote:

- i'll add chat too, within a room only

Well, that one is fully out of the box Lite-compatible: just send your chat messages around to all players in the room or to specific target actors or receiver groups with opRaiseEvent(), like you would do with any other in game data, preferable on as separate channel.

Tobias

As you are working on persistency anyways, it should be not a big deal to check a player's list of games and send a event to the peer when it's her turn. This work can be done in the Peer class (as it doesn't affect a room directly).
A direct chat could also be realized this way: If someone sends you a message, it goes into the DB as "my messages".

I think you can still subclass AppBase and Peer.

mindlube

That's good advice- thanks Tobias! However I should to avoid having each Peer poll the database to see if there are updates to their subscribed games. But I just realized that I could use the Server-Server API to push events to other peers. In the situation where a game state is updated, but the player is connected to another game/room.

Supposing one makes a Lite implementation of their game. Technically - what's required to enable Load Balancing? (other than having 2+ servers, I assume. 1 LoadBalance+Lobby, 2 or more Photon servers)

Tobias

Comparing Loadbalancing to Lite, it keeps the features of rooms but adds a master server to distribute rooms and users across available machines.
This change of servers is a workflow we implemented in the LoadBalancing API that is now part of the client SDKs.

It's somewhat different but not too much. Example: In Lite, the Join operation results in being in a room (or not) but in LoadBalancing, it will get a game server address, disconnect, connect to GS and then join the room. There are 2 Join responses in the LadoBalancingClient and it goes through different states.

You might want to include LoadBalancing in your project from the start, so you don't have to change your game's state machine later on.
The LoadBalancing solution in the Server SDK is setup to run on a single machine, locally, out of the box. It's not really extra effort to run it.

Edit:
Yes, you should avoid to poll the DB for user interaction. I'm not sure if that's true for memory cached DBs as well though.

mindlube

ok thanks again!

Philip

mindlube wrote:

That's good advice- thanks Tobias! However I should to avoid having each Peer poll the database to see if there are updates to their subscribed games.

Yes - you should avoid "having each Peer poll the database" that won't scale.

mindlube wrote:

But I just realized that I could use the Server-Server API to push events to other peers. In the situation where a game state is updated, but the player is connected to another game/room.

But you could use an external cache (e.g memcache), where you track
- players connect status (connected:true|false, server:1|2|...)
- game-state (players-turn:playerA|playerB|..., list-of-players-ingame: ..., ...)

Use the cache to
- list the players games and who's turn is on
- pull the state of game for a game the player want's to make its move
- update the game state after move
- post a notification per S2S api to the server the "other" player is

For this architecture a "standard" loadbalancing rule (e.g. per num-connections, dns-round-robbin, etc ) would be enough.

Assuming your players are only in one chat at the time - you could even mix this turn-based-game architecture - with our
loadbalancing. Letting the players create/join rooms to chat. Our loadbalancer will distribute the chat-rooms accross
your machines.

mindlube wrote:

Supposing one makes a Lite implementation of their game. Technically - what's required to enable Load Balancing? (other than having 2+ servers, I assume. 1 LoadBalance+Lobby, 2 or more Photon servers)

Yes 2+ servers - thats it. At the beginning the loadbalance/Lobby Server (we call it Master ) can also host a game service.