Photon and Redis *

yoda

I currently have 3 games live in european social sites that are running on a java based socket server aka smartfox. I am in the process of writing the software design document since i have completed the requirements document.

my question for this forum is if i use the standard photon installation with master server - game simulation servers how, if i can, implement redis in this installation. if a user starts on server b and gets bounced over to server c during the same session how can/should i expose the key value pairs? im affraid if i hold everything on the mater server that i will create the first point of failure during ccu spikes. redis does support clustering however not on windows based rigs. my memory footprint per user is small (very).

I appreciate any knowledge you can offer. Thanks.

Tobias

Not sure if this helps but: Players connect to the Master Server to find games and each game more or less resides on a single game server. So once in-game, the players don't switch servers again.
If you use Redis for accounts and some data, each server has to connect to it and get/set it. For non essential data, the clients can "carry" the data between servers (e.g. nickname).
Aside from this, Photon does not limit you in any way in terms of server side implementation. You have the full DotNet framework at your service.

I hope this helps a bit. If not, let us know what you try to achieve.

yoda

Thank you Tobias for your reply. Im running matchmaking services on photon as I do in smartfox, user migration is probable. I also run friends list and public/private lobby systems with a invitation system. Including the ip/port in invitations should solve the actual migration. But user A d/c from box 1 going to box 2 has session data (value pairs) that hasnt been persisted so I need to either run all my data requirements off of a dedicated db/wcf box (probably all the same box at launch) or migrate the subset with him on d/c. I was wondering if photon exposes a cleaner solution to this rather than stuff everything in a property bag or nickname field and send him off. Or are you saying the nickname is the cleaner solution lol?

Tobias

There is currently no cleaner way than to put something in custom properties or use the nickname.
Photon is relatively ignorant of what one or another system (account, external matchmaking) is doing. This can be positive as it doesn't get in your way but in this case, I guess it means you need to customize it a bit.
Instead of using the name you could also hand over a temporary token that the servers use to access a client's "session" and data. In most cases, a central, dedicated DB has benefits. Aside from the administration, it's always good if you can scale it independently.