[Cloud]confused on workflow of Cloud && database

garric

Hi,
I'm still confused on the basic workflow using cloud.

It's said that Cloud just forward operation and response, game server logic has to be implemented in game server client by ourself.(Is that right?)
This is the imagined game scenario,
A client request to visit database server, is that to say,
1. the client first has to send operation to Cloud
2. the Cloud forward this operation to our game logic game server
3. game server deal with this operation and query database
4. game server send result from database in the form of response to Cloud, and then from Clout to client
or
4. game server send result from database in the form of repsonse directly to client?


By the way,
Persistency is currently not coverded in the SDKs.
So, whether planning to use Photon Cloud or not, we have to host and maintain the database server by ourself?

Philip

Hi garric,

currently the cloud isn't really designed to support autoritative game servers.

But yes in general is possible to do what you describe - your server would have to be the instance creating the rooms, that players join.

If you need more than just a couple of custom server operations - something like an authoritative server you should probably look into hosting yourself - you can start based on the load balancing project, which gives you the same feature set as the cloud and you get in source code in our sevrer sdk.

Recommended Architecture
The other possibility to integrate custom server logic is letting your clients communicate with your server directly.
Clients could for instance call your server to login and get their profile. Once they join a room (on the cloud) they could publish their userId and the other players once they get the userid from the cloud get the public-profile calling your server.

garric

@Philip
Thanks for your help.But there's still two questions.
1."Once they join a room (on the cloud)", you mean the room is the Lobby? In the Loadbalancing project, the AppLobby is binded to MasterApplication, so I guess the room you mentioned is just the Lobby.
2.In the Loadbalancing project, I haven't be clear of some definition.
2.1 public address & master address
In my opionion, the master address is enough for GameServer. Why public address is used? Public address is for proxy, because GameServer with their own virtual ip in LAN sharing only one IP(Public address) to WAN? What's the relationship between public address and master address.
2.2 internal address & external address
This is more confused.
2.3 localNodeId & masterNodeId
It's coded that, if localNodeId equals masterNodeId, then this node is master. I have been thought that, masterNodeId is always 0 and only assigned to MasterServer(responed to MasterApplication). Every GameServer is assigned a unique a localNodeId. Is that right?
And at the same time, it's said that, the NodeId is related to proxy.
What if without these NodeId!

Philip

garric wrote:

@Philip
Thanks for your help.But there's still two questions.
1."Once they join a room (on the cloud)", you mean the room is the Lobby? In the Loadbalancing project, the AppLobby is binded to MasterApplication, so I guess the room you mentioned is just the Lobby.

No - i mean rooms/games on the game server. The Lobby is also a room but only there to manage the list of games on the gameservers and coordinate the matchmaking. Your game server would have to create games for your players to join.

garric wrote:

@Philip
2.In the Loadbalancing project, I haven't be clear of some definition.
2.1 public address & master address
In my opionion, the master address is enough for GameServer. Why public address is used? Public address is for proxy, because GameServer with their own virtual ip in LAN sharing only one IP(Public address) to WAN? What's the relationship between public address and master address.
2.2 internal address & external address
This is more confused.

Please see thsi thread viewtopic.php?f=5&t=1477&p=6872&hilit=PublicIp#p6872.
And if still not clear - post your questions there.

garric wrote:

@Philip
2.3 localNodeId & masterNodeId
It's coded that, if localNodeId equals masterNodeId, then this node is master. I have been thought that, masterNodeId is always 0 and only assigned to MasterServer(responed to MasterApplication). Every GameServer is assigned a unique a localNodeId. Is that right?
And at the same time, it's said that, the NodeId is related to proxy.
What if without these NodeId!

The nodeId might be a bit confusing - sorry. Its code reminiscent from our Azure solution - in your case asume its always 0 where it basically has no function other than telling the master that it is the leader and should respond to requests.

zm044

Hi Philip,

We would like to make clear the structure of Photon Cloud firstly. We drew 4 diagrams to describe possible structure of Photon Cloud.
This email was written by @garric in fact.

MS: MasterServer
GS:GameServer, responsible for rooms maintenance, not for specific game logic

GL:GameLogic, implementation of specific game logic
DB:Server for hosting DB , storing persistent infos, e.g. states for games and access lists for authentication.


Scenario I

All MS and GS are hosted in Cloud. GL are binded to GS as extention for specific games.
DB and AS are hosted in Cloud too.
So, once the game logic, as well as authentication process, are implemented. All these can be left to Cloud for maintenance.




Scenario II
The only difference with Scenario II is that, the Cloud don’t support DB.
So, developers have to deploy DB on their own server, even host the AS on their own server.




Scenario III
Even the GS is not hosted in Cloud? Cloud are only offer MS.
All these GS and GL as extention to GS should be deploy on the developers own server.
However, in this Scenario, the size of GSs can’t not be automatically scaled. I mean, whenever the num of clients increase, we have to add and register GS by ourselves. This seems not convenient.
So, the Scenario may be the most impossible, we guess. Is that right?

zm044

Scenario IV

This imagined architecture in Cloud is almost the same as the Loadbalancing Framework(going along with the Photon SDKs zip file) presents.
Developers need not to focus how the room are maintained, but they have to implement the specific game logic and deploy it on their own server. For example, the MasterClient just plays the role of execution the game logic.

dreamora

None of these models are scaleable to cloud (or as in case of 3 not even related to the cloud anymore at all), no matter how you turn it.

The first two would scale but would allow unrealistic loads on the server caused by bad code.

The third model is the only one that could even work, but it introduces major security problems and it does not have the slightest thing to do with cloud anymore if you host it yourself. In such a case you can simply fire up an own master as the master is light enough to run on a 1 & 1 VPS without a problem, the thing that really has to work like stupid is the game server This is basically the model thats called 'host your own LoadBalancing instance'

And the 4th one is totally unusable, by any scale and from any PoV. Not only is it completely unmaintainable, the ultra latency it introduces makes it totally unusable too, basically even playing on 2G phone or satellite uplink would be worlds more enjoyable than playing there as we talk about latencies in the seconds range, if you are lucky.

Philip

zm044 wrote:

Hi Philip,

We would like to make clear the structure of Photon Cloud firstly. We drew 4 diagrams to describe possible structure of Photon Cloud.

Scenarios I, III are not supported.

Scenario II ... we are starting to offer what we call "private cloud" services this is not out of the box and done on a project basis.

Scenarios IV ... might be an option depending on what you are trying to do.
Keeping in mind the cloud has not a specific api/interface for such a "game logic".
For the cloud it is "just" a client.

garric

Err...there seems a confict between Philip's view and dreamora's, eapecially for the fourth Scenario.

@dreamora
"And the 4th one is totally unusable"
@Philip
Scenarios IV ... might be an option depending on what you are trying to do

Now that the Cloud has nothing to do with specific game logic, there is only one way for us to choose, implementing game logic outside of cloud, right?

Second, could you please draw an draft to explain it, which may be more direct and clear.

Philip

garric wrote:

Err...there seems a confict between Philip's view and dreamora's, eapecially for the fourth Scenario.

@dreamora
"And the 4th one is totally unusable"
@Philip
Scenarios IV ... might be an option depending on what you are trying to do

If you are planing an authoritative server - for a shooter or a racer - dreamora is definitely right.
To be honest - i don't know of anybody following this strategy. And as said at the begining of the thread
its not the recommended way.

garric wrote:

Now that the Cloud has nothing to do with specific game logic, there is only one way for us to choose, implementing game logic outside of cloud, right?

Second, could you please draw an draft to explain it, which may be more direct and clear.

Well it might mean you shouldn't use the cloud and host your self - bottom line in the cloud:
- put the game logic in the master-client
- persistency - let the clients communicate with your service directly

dreamora

My point against Scenario 4 is that with a octa jumps (client - cloud - game logic - cloud - master client - cloud - game logic - cloud - client) you get a latency at which point you can simply stop to develop with photon and use HTTP request against a REST webservice, cause its for granted faster (latency wise and server load / traffic wise)

Naturally if you use master clients that are hosted in your own private hosting environment then Scenario 4 is what you have already today, as the 'game logic' then would be the master client and you would only have the quad jumps from client - cloud - game logic - cloud - client

Philip

dreamora wrote:

My point against Scenario 4 is that with a octa jumps (client - cloud - game logic - cloud - master client - cloud - game logic - cloud - client) ...

Interesting didn't see this as a possible scenario .

dreamora wrote:

Naturally if you use master clients that are hosted in your own private hosting environment then Scenario 4 is what you have already today, as the 'game logic' then would be the master client and you would only have the quad jumps from client - cloud - game logic - cloud - client

This is the scenario I had in mind - but even then ... you're adding the complexity of having to manage to join your "hosted master clients" to the rooms. You would also still have to invest in making your servers failsafe and scaling. Unless ...
the reason to have "hosted master clients" is to suppress cheating, a strategy you could follow is to randomly join "hosted master clients" - meaning that your game falls back to a normal "master client" if your servers are overloaded or not available. You can than start banning people that cheat ...

dreamora

Its trivial to do that. Command line arguments when firing up unity headless clients / standalone other clients makes this trivial.
We do it ourself with LoadBalancing clients, anyone not able to do that does not need server logic either if trivial day 1 knowledge programming tasks are impossible

Also the failsafe situation is likely always a problem isn't it. Even with the cloud, when everyone could add custom logic I am going to guarantee you that the least stable running photon loadbalancing instance on globe would be yours, the ExitGames one.
The benefit of the master client out of my view is exactly the trivial scaling and failsafe. Fire up a new VM with additional master clients and you have other rooms that run on their own. Do that 200 times and you happily scale beyond any realistic userbase The message forward scaling which normally would hit in as a problem at some point is completely covered in the cloud / LoadBalancing environment.

All you need is a simple Java / Ruby / what else core service that you can reach from your central management place that fires up new master clients at will and that feeds them the required parameters, but thats really as trivial as it could become, thats a thing you could even do with them being started on machine start and have them polling a db every 5s to see if they are meant to start a new master client and if so with what params. (thats how some MMO clusters work by the way, the Monumental Technology Suite does EXACTLY that )

Philip

dreamora wrote:

Its trivial to do that. Command line arguments when firing up unity headless clients / standalone other clients makes this trivial.
We do it ourself with LoadBalancing clients, anyone not able to do that does not need server logic either if trivial day 1 knowledge programming tasks are impossible

As always it depends on what you're requirements are - there might be issues you run into once you have 1000+ rooms (which some of our customers ran into).

dreamora wrote:

Also the failsafe situation is likely always a problem isn't it. Even with the cloud, when everyone could add custom logic I am going to guarantee you that the least stable running photon loadbalancing instance on globe would be yours, the ExitGames one.

no it wouldn't - we are supporting custom logic only once we can make sure we shield customers from each other.

dreamora wrote:

The benefit of the master client out of my view is exactly the trivial scaling and failsafe. Fire up a new VM with additional master clients and you have other rooms that run on their own. Do that 200 times and you happily scale beyond any realistic userbase The message forward scaling which normally would hit in as a problem at some point is completely covered in the cloud / LoadBalancing environment.

yes

dreamora wrote:

All you need is a simple Java / Ruby / what else core service that you can reach from your central management place that fires up new master clients at will and that feeds them the required parameters, but thats really as trivial as it could become, thats a thing you could even do with them being started on machine start and have them polling a db every 5s to see if they are meant to start a new master client and if so with what params. (thats how some MMO clusters work by the way, the Monumental Technology Suite does EXACTLY that )

Well then I guess you changed your mind and see Scenario IV is a good option .

dreamora

Oh I never saw it as a bad scenario when used with master clients.

But the original sketches weren't relying on master clients but GL in the cloud + the current cloud architecture and then I consider it a seriously bad architecture

Philip

dreamora wrote:

Oh I never saw it as a bad scenario when used with master clients.

But the original sketches weren't relying on master clients but GL in the cloud + the current cloud architecture and then I consider it a seriously bad architecture

Well we don't know what garric is planing to do - is it a unity based game? Then you are right assuming that the GL most probably is a headless unity instance - although not necessarily the only option to develop a "master client".

If it is not unity based - you could implement without unity headless instead you could do it in photon.
Conceptually it would be the same ...

dreamora

Why would it be the same thing? If GL is a independent game logic instance then there is still client and master client.

Or am I wrong on this small detail? I thought those concepts apply to all LoadBalancing client SDKs, not just the Unity one.

Philip

dreamora wrote:

Why would it be the same thing? If GL is a independent game logic instance then there is still client and master client.

Or am I wrong on this small detail? I thought those concepts apply to all LoadBalancing client SDKs, not just the Unity one.

The sdk support for "master-client" is specific to unity PUN and has its origin in the original unity networking sdk (afaik).
The other sdk's don't have a a pre-implemented "master-client" ... but the concept itself is generic in the sense that you have one "special" client instance that will have some custom game logic the others don't have (at least not in an active modus).

Note: IMO even in unity using the built in "master-client" is optional.

dreamora

I see

I know that the master client is optional but whenever 'safe logic' is involved its by far the easiest way to achieve it, as there are no projects that easily integrate with Photon due to its C# layer. Either engines are native code (all physics middleware, most game engines) which one would not want to bind against photon due to the overhead and the impact on the otherwise relatively threadsafe environment or they are incompatible with photon (neoaxis, unity, ...)

zm044

Thanks for Philip and dreamora’s help.
It looks like more clear to me on Photon Cloud now. Anyway, I want to validate it again, sorry.
And more important, we will first get rid of the GL, or MasterClient (we have mentioned before)to make it simple and clear.

1．What Photon Cloud offers:

This is exactly what Cloud offers on Loadbalancing architecture, is that right? GS is responsible for basic room management, and MS is responsible for GameServer management.

All the following presentation is based on the assumption that the view of ‘What Cloud offers’ is right.

2.What happens if two Client want to chat

The key factor is how the MS and GS deal with opeartion. I mean, in the local Loadbalancing framework project, MS and GS just deal with 4 or 5 operations, leaving other opeartions as ‘Unknown operation’ and directly sending back to Clients.
So, the MS and GS on Cloud is just implemented as same as the way like that?
Or,
Except the basic opeartions, like join, leave…operation, the other operation is just forward? But forward to who?
For clarification, the Scenario is that ClientA and ClientB enter into one room and have a chat. The steps is this(one room hold one game),

a.) ClientA send CreateGame request to MS, and MS return the min-workload GameServer address to ClientA.
b.) ClientA connnect to related GameServer accorrding to address and creat a room on this GameServer
c.) ClientB send JoinLobby request to MS, and MS return the roomlist to ClientB.
d.) ClientB entery the room created by ClientB with roomId.
e.) MS may send event to all the peers(ClientA and ClientB now) in the rooms to notify that ClientB join the room. And more important, ClientA and ClientB know each other’s IP address.
Now, ClientA and ClientB are in the same room. So, they may have a public chat or private chat. And the operation for public chat is named opPublicChat, and opPrivateChat for private chat.


2.1 public chat
ClientA send a opPublicChat to GS, which GS doesn’t recognize it.
So GS will forward it? But to who, and according to what? The implementation may like this,
GS just send to all as event, and every peers in this room will receive it.

2.2 private chat
ClientA send a opPrivateChat(inlcuding ClientB’s peerID, or something like this that can identify ClientB) to GS, which GS doesn’t recognize it.
So GS will forward it? But to who, and according to what? The implementation may like this,
GS just send to as event, and every peers in this room will ‘check’ whether if the peerID is just themselves? (This will cause message flood? All mentioned so far are like boardcasting)
Or
Some other implementation?

3.What happens if more Clients want to play card
This is invloled with speicif game logic now. Ok, who is repsonsible for specific game logic. The first Client which also creates the Game(or Room), or a master client(only specially for game logic)?
i. If it is the first Client, what happens when it exits the game(or room)? The game(or room) forces to discard and all the other Clients return to lobby. But this first Client seems a little heavy for game logic, is that right?
ii.If it is the master client(a special client), this seems more reasonable. So then, the game workflow will like this,
a.Master client will first create the game(or room)
b.All the other clients will join the game and everytime a client joins, the game server boardcastes this operation and master client judge whether this client num is enough to start this game.
This seems like that, each operation is like this,
Client(including)send operaton to GS
GS boardcast opeartion in the way of event to ALL clients
Client(including)deal with this operation, seperately.
Is this workflow right? And more important, this kind of boardcast will cause message flood?

What’s more, if the chart above is not right, may you correct it and draw it in this thread.

Thanks.
(This post was done by garric)

dreamora

Upfront: There are no such operations and if you want to use the cloud you can not add them. Adding own operations, hence changing the MS or GS code, is only possible when you host an own Photon server.
But naturally there is nothing preventing you sending an event 'chat' with a flag for private, public, xxx


e) thats wrong. The MS only handles forwarding to the GS and room / lobby.
The whole room related messaging is handled by the GS you are on and clients that are connected to the cloud then are connected to the GS only (on join you go to the MS, after the forwarding you fully reside on the GS, you don't talk to the MS anymore as long as you are on the GS)

Also operations only exist on the photon server, not on clients. Clients only handle operation responses and events, be it the normal client or the master client.

2.
Such the operation would need to be implementated on the Application of the GameServer not in the master server logic, on your own photon server then.
And no the photon server won't broadcast things that are not defined to be broadcasted. Normally thats the case only for raiseevent which are 'untargeted' as no target = everyone


3. If you have no need for persistent rooms / special roles / authority, you don't need a master client to handle the game logic. But you can naturally have one

3.i / 3.ii: the next one is assigned as master and the corresponding op fires. if a regular client leaves then the photonplayer disconnect is the only thing that fires
3.b: the GS only broadcasts whats meant to be broadcasted. Operations normally are not broadcasted as they only exist on the GS. Whats being broadcasted are events or the 'processed result' of an operation when you request something. But there are also things that are sent to specific clients only.

Otherwise this is right, if you don't target specific clients its an all to all relationship and causes message flood (or makes you hit the messages per second limit on the cloud pretty fast )

garric

Thanks, dreamora

dreamora wrote:

e) thats wrong. The MS only handles forwarding to the GS and room / lobby.
The whole room related messaging is handled by the GS you are on and clients that are connected to the cloud then are connected to the GS only (on join you go to the MS, after the forwarding you fully reside on the GS, you don't talk to the MS anymore as long as you are on the GS)

Yeah, this is my fault. I found this as soon as it is posted.

dreamora wrote:

If you have no need for persistent rooms / special roles / authority, you don't need a master client to handle the game logic. But you can naturally have one

Take play card for example. May there's a need that 52 cards have to be divided into 3 random group. Then this can be regarded is the special roles, so we need the Master Client. Is that right?

dreamora

Not needfully. You could do it but as in realworld, when you play with 2 friends, there is no 'special role' that only does splitting the cards into 3 staples. Its a role one of the 3 of you has temporaly and for a card game you could do the same. With the expectation of leaving and joining players in a room (assuming you will allow that) having a dedicated 'split role' thats persistent and bound to the room owner to me seems like an overkill unless you really want that role, where one player 'hosts the card game' and 3 others are playing it (like a crupier in a casino)

garric

@dreamora
lol...I got it.
I'm clear on Photon Cloud now. \
Thanks very much, and also Philip.