Crazy Question: using Photon Cloud AND Server
Options
BFGames
✭
Is there a restriction of people being connected to both photon cloud and our own hosted photon server at once? Guess not.. 
The problem is that while photon cloud is perfect for our, heavy physics voxel world, game. Letting people update things into the database via Unitys WWW class creates a large breach where they can snap up the post information and update scores and such outside of unity.
Now with a photon server we can prevent this by only letting updates from the server being allowed.
So when joining the game (photon cloud), it will also join people to our own hosted photon server, which will be used only to send, validate and receive information for the database (very limited how often we will need to send anything, so should be handled on rather cheap server, which is important)
So is that possible? (We could also use it for lobby chat now i think about it
).
The problem is that while photon cloud is perfect for our, heavy physics voxel world, game. Letting people update things into the database via Unitys WWW class creates a large breach where they can snap up the post information and update scores and such outside of unity.
Now with a photon server we can prevent this by only letting updates from the server being allowed.
So when joining the game (photon cloud), it will also join people to our own hosted photon server, which will be used only to send, validate and receive information for the database (very limited how often we will need to send anything, so should be handled on rather cheap server, which is important)
So is that possible? (We could also use it for lobby chat now i think about it
). 0
Comments
-
Would be really nice with an answer for this. Does the Photon3Unity3D.dll for the cloud service come with what a need for also using Photon server along side the cloud?
If not, will they collide in some manner?0 -
Just created a small test game and seems like it works just fine being connected to both 0
-
Sorry for the late answer.
There is no restriction in connections per client but PUN doesn't make your life easy trying to do that. We built it to resemble Unity Networking and while doing so, we used a lot of static variables and methods that in turn get you stuck with one connection for PUN.
I don't think you can add the regular LoadBalancing api to a PUN project, which means you might need to refactor some more code to run multiple connections.
This would be easier with the LoadBalancing API from our "Plain" Unity SDK. But with that you might be missing PUN features.
https://www.exitgames.com/download0 -
Ahh fair enough. Have not ran into any problems yet though.
Only using a Lite Server setup, because i just need simple rooms for handling login/player chat/database calls.0 -
The Room class in LoadBalancing is almost identical to that in Lite. The extra stuff is wrapped around that and doesn't even need more machines either.
Just keep in mind it's there
0 -
I will!
At the moment all i need is to send Custom Operations, i then define what to do based on a shared library of enums between client and server.
For example send a chat msg, ask for a friend request or get some infomation from our database (like ranking score).
Works well so far.
By the way:
Would it be a problem to have like 500 people in a room as long as it is only for chatting, and then keep track of the channels in a list? What would be the downside of doing so instead of dividing chat into separate rooms for each channel?0 -
I don't see a real downside for the chat scenario.
Per room, every incoming Operation is executed serially but the message queue runs a lot more messages than that.
You might want to adjust our events join and leave Either not send them at all or streamline them.
Ev Join contains the player list and is sent to everyone (again and again) when someone joins. You better send that in the Op Join response and cache it, if you really need it. Ev Join only needs the actorNumber and name of the new user for everyone. Skip properties aside name, maybe.0 -
I see a problem in allowing public chat messages to the whole room: With 500 people per chat room that are actively chatting this can mean an awful lot of messages. If every chatter sends just 1 message per minute to the room, then with 20 people in the room that would mean 20x19==380 messages per minute, or 6.33 msg/s, but with 500 people it would already mean 500*499==249,500 messages per minute or 4,158 msg/s, so 500 players in a single room would create the same amount of traffic like 13,140 players in 157 rooms of 20 players each. That's the reason why chat rooms are normally limited to reasonable amounts of people in them.
If one should not be able to chat with everyone else in the room anyway, then I don't see any sense in putting all the players into the same room: Just put those players into the same room, that actually should be able to chat with each other.0 -
I think you need to think rooms as a practical implementation and not a concept.
If i had 500 in a room, they would not all be in the same channels. Keeping a list of channels containing chat log and UID's is rather easy with a dictionary. I could have 20 channels with 25 in each for example.
If you send a messages you will always define a channel and then only send messages to the relevant users.
This makes it easy to have people in multiple channels at one time and send private msgs across channels with ease.
And Tobias i already chnanged join and leave as i could see it would send a response to everyone
0 -
Anyways it will show if my server crash and burns 0
-
I just wanted to mention that a chat room with 500 people in it all able to send a lot of messages to everyone else in that chat room all the time would not be ideal, as I have not been sure, if that could maybe be your intention. As long as you restrict the max receivers somehow rooms with that amount of players in them for sure can work out. Just be aware that the max amount of channels per room is restricted to 255 (0-254, as channel 255 is reserved by Photon itself for system messages) by the API and the client-server protocol, so that you would have to combine them with receiver groups and/or target actor lists, if you should need even more.
The default amount of channels is much lower than that (afaik it's set to 2 for PUN), but setting that to a higher number is really no problem.
Actually target player lists are the better approach than channels, although its may be a little bit more work to manage them. Channels still mean, that everyone in that room will get that data. The concept of channels is there to organize priorities: a lower channel number means a higher priority, so that in case of messages queuing up, those in channel 0 would reach their receivers prior to those in channel 1 and so on. They are not intended as a grouping mechanism for players. That's what target player lists and receiver groups are for.
Keep the phone number of the fire department at hand! Just kidding ;-)BFGames wrote:Anyways it will show if my server crash and burns0 -
BFGames: Your "channels in room" are what we implemented as "interest groups". We currently use one byte to define the group that a message goes to. Players can subscribe interest groups or ignore them at will. The server currently is the only instance which knows who is listening to which groups. This is not sent to clients.
You could build on top of this and remove the join/leave events or at least streamline those.0
