We need to create a game with 10 + 1 users.
10 players will be real users - in this multiplayer online game.
The 1 player is a dealer which will be the app software - who will work like a dealer.
This dealer will NOT be a real player. This dealer will be throwing DICE.
How can we do it in photon PUN ? We are using the FREE version of photon
right now.
Depending on the Photon client SDK you use, you should have a callback of when Master Client is changed (should be "OnMasterClientSwitched").
This is triggered when server detects that Master Client is disconnected.
Master Client should be the actor with the lowest actor number but there is a way to force the Master Client (change it from client).
If you save data in room properties or send events and maybe cache them, then there is no risk of data loss as it will be there as long as the room is still "alive". Actor properties on the other side, should be cleaned up when the respective actor leaves the room.
One tricky situation though: when the Master Client is not responding and did not explicitly disconnect, there may be few seconds (default timeout 10seconds) before the server detects that that actor timed out and switches to new one. If this situation concerns you, for instance if you target mobile, we can discuss possible solutions.
Related
In a Big-IP LTM system I have http monitors setup for a pool so that system owners can remove a file a node in the pool to remove a node from rotation. But monitors mark a node as disabled, not offline, so cookie-based persistence will still send existing users to the node that should be down. Whats the best way to use monitors to either offline a node instead of disabling it, or forcing users to a new node despite persistence?
Disabling a pool member still allows active connections/persistent connections to function. And depending on how you have persistence defined, that can end up being a LONG time.
Forced Offline still allows active connections to complete their transactions but would move previously persisted traffic to other nodes.
When doing maintenance I would force the node offline and then give sessions 5 to 10 minutes to complete before taking the node down in infrastructure. There's no good way to drop a node with active connections further dependent on what the client is actually doing.
Here's a great response on F5's Community by one of their MVP's to help explain connections.
Pool Member disabled/forced offline behavior # DevCentral
Let me know if you need more details or if you're seeing different behavior. Also, you can do all of this with REST API so you don't need to use the GUI. Doing a quick Node Offline/Online is super easy and quick.
One of the features of Erlang (and, by definition, Elixir) is that you can do hot code swap. However, this seems to be at odd with Docker, where you would need to stop your instances and restart new ones with new images holding the new code. This essentially seem to be what everyone does.
This being said, I also know that it is possible to use one hidden node to distribute updates to all other nodes over network. Of course, just like that is sounds like asking for trouble, but...
My question would be the following: has anyone tried and achieved with reasonable success to set up a Docker-based infrastructure for Erlang/Elixir that allowed Hot-code swapping? If so, what are the do's, don'ts and caveats?
The story
Imagine a system to handle mobile phone calls or mobile data access (that's what Erlang was created for). There are gateway servers that maintain the user session for the duration of the call, or the data access session (I will call it the session going forward). Those server have an in-memory representation of the session for as long as the session is active (user is connected).
Now there is another system that calculates how much to charge the user for the call or the data transfered (call it PDF - Policy Decision Function). Both systems are connected in such a way that the gateway server creates a handful of TCP connections to PDF and it drops users sessions if those TCP connections go down. The gateway can handle a few hundred thousand customers at a time. Whenever there is an event that the user needs to be charged for (next data transfer, another minute of the call) the gateway notifies PDF about the fact and PDF subtracts a specific amount of money from the user account. When the user account is empty PDF notifies the gateway to disconnect the call (you've run out of money, you need to top up).
Your question
Finally let's talk about your question in this context. We want to upgrade a PDF node and the node is running on Docker. We create a new Docker instance with the new version of the software, but we can't shut down the old version (there are hundreds of thousands of customers in the middle of their call, we can't disconnect them). But we need to move the customers somehow from the old PDF to the new version. So we tell the gateway node to create any new connections with the updated node instead of the old PDF. Customers can be chatty and also some of them may have a long-running data connections (downloading Windows 10 iso) so the whole operation takes 2-3 days to complete. That's how long it can take to upgrade one version of the software to another in case of a critical bug. And there may be dozens of servers like this one, each one handling hundreds thousands of customers.
But what if we used the Erlang release handler instead? We create the relup file with the new version of the software. We test it properly and deploy to PDF nodes. Each node is upgraded in-place - the internal state of the application is converted, the node is running the new version of the software. But most importantly, the TCP connection with the gateway server has not been dropped. So customers happily continue their calls or are downloading the latest Windows iso while we are upgrading the system. All is done in 10 seconds rather than 2-3 days.
The answer
This is an example of a specific system with specific requirements. Docker and Erlang's Release Handling are orthogonal technologies. You can use either or both, it all boils down to the following:
Requirements
Cost
Will you have enough resources to test both approaches predictably and enough patience to teach your Ops team so that they can deploy the system using either method? What if the testing facility cost millions of pounds (because of the required hardware) and can use only one of those two methods at a time (because the test cycle takes days)?
The pragmatic approach might be to deploy the nodes initially using Docker and then upgrade them with Erlang release handler (if you need to use Docker in the first place). Or, if your system doesn't need to be available during the upgrade (as the example PDF system does), you might just opt for always deploying new versions with Docker and forget about release handling. Or you may as well stick with release handler and forget about Docker if you need quick and reliable updates on-the-fly and Docker would be only used for the initial deployment. I hope that helps.
I'm developing a realtime game using Sprite Kit and Game Kit. The game features a multiplayer mode where 4 players can play with each other. I've been reading the Game Kit programing guide and came across the following passage:
Although the GKMatch object creates a full peer-to-peer connection
between all the participants, you can reduce the network traffic by
layering a ring or client-server networking architecture on top of it.
Figure 8-1 shows three possible network topologies for a four-player
game. On the left, a peer-to-peer game has 12 connections between the
various devices. However, you could layer a client-server architecture
on top of this by nominating one of the devices to act as the host. If
your game transmits to or from the host only, you can halve the number
of connections. A ring architecture allows devices to forward network
packets to the next device only, but further reduces the number of
connections. Each topology provides different performance
characteristics, so you will want to test different models to find one
that provides the performance your game requires.
So here is where I am confused. Currently in my game I have implemented the peer-to-peer topology, where each user sends their position to every other player in the game. This ends up totaling 12 messages being sent, because each player sends 3 messages.
However according to the documentation, if I layer a client-server topology over my game, I can reduce the network traffic by reducing the number of connections. If I do this though, then each client will send their position to the host and then the host would need to relay those positions to the remaining clients. So now one player (the host) needs to work extra because the clients no longer communicate with each other. And then we still end up with 12 messages. The host sends 9 messages (3 messages for each player, plus 6 messages for relaying the other clients' positions) then each client sends 1 position message to the host. 9 + 1 + 1 + 1 = 12 messages. Which makes sense, all we did was unevenly distribute the message sending, so now one player needs to work harder to makeup for the less work the other players are doing.
Furthermore, relaying the client messages takes additional time because each client's position now needs to pass through the host.
So while there are now less connections, one player is sending more messages (9 messages) rather than each player evenly distributing the workload (i.e. each player sending 3 messages). This seems like it would lead to a greater chance for disconnects to occur because it will be easier for the host to disconnect from the match.
So can someone explain to me how network traffic gets reduced by layering a client-server topology? Does just the fact of having less connections in the match reduce network traffic even though overall messages are the same? Keep in mind, there is no dedicated server here, I (and the documentation) am talking about layering a client-server topology on top of the peer-to-peer match. Also isn't the host at a greater chance of disconnecting because he is sending 3X as much messages as the other players. After all, the GKMatch will disconnect a player after a brief period of packet loss. Or does simply the fact of having 12 connections have a greater chance for disconnects because of the supposedly increased traffic?
I am sorry for the very short answer to a very descriptive and well written question, but the answer is simple. The Server (you used the term "host", but this is confusing) does not have to send 3 separate messages to each client. The Server collects all the information and sends just one message containing all information to each client.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I started to make multiplayer game but as I have no expirience I tried it different ways but something doesn't feel right to me.
So, I really need an advice about which platforms/tools/languages/techniches I should use best.
I must say that I don't believe in things such as: Photon, AppWrap, Skiller, Gamooga and others. I dont believe they will scale great and it won't be too pricey, or they are too big (I don't mean size, I mean how much things they has that I don't need) for my needs.
First, I'll describe simplified game session proccess.
Three players starting the game session
Each player receives a question and should answer within 10 seconds.
When player answered he should be able to see any answers that were given already by any other players (if any) and he should be able to see any answer given as soon as it was given. Basically, any answers should be received by other clients in realtime but only after we answered (to avoid cheating). If time is out then any who doesn't answered will receive no score and next question goes.
Deciding winner and goes to the next question. Finish the game session after N rounds.
Second, I'll explain few requirements that I taken into consideration.
Game should be run on iOS/Android/Web. This leaves me no choice but to make it based on HTTP.
I looked for Google Cloud Endpoints about which I was really enjoyed. It has iOS/Android/JS SDKs, Google Cloud Platform has Google BigQuery, and many other great things. But because I need realtime answer delivery I don't know if that suitable (there is Channel API but no client SDK for iOS, and people saying its not that good).
Then I looked for Node.js and long polling (AFNetworking on client side) but it is so hard to manage. I need to serve game state updates to clients (and I need to send deltas). That way I need to track all changes individually for each player. And when player connects I should check if there any changes already; if it is then send right away; if it isn't then listen for 'change' event and then send. In the end code looks so awkward and hard to understand and I don't know how to make it right. There is socket.io which should make things better on the server side but again no iOS SDK for client.
I don't know where to go from here. Any help would be very appreciated.
Turn based architectures are actually not too complicated as lag is really not a huge concern, and data is not being sent constantly.
I would create two web services, one for matchmaking and another to handle the actual game.
The matchmaking would simply queue up players, when there were enough for a match, the service would pick a group of players and assign them a sessionID and pass the players to the game service.
For the game service, it is important to differentiate what can be handled on the client and the service.
The game service would store all game information for each sessionID including clients. This would allow a single service to manage hundreds of games at once with ease. When a player answered a question it would send that in a request to the server with the sessionID. The server would iterate over the clients in the session and send the information to them.
The client could handle hiding questions until the user has answered. (You could even encrypt the other question information if you were concerned about hacking).
The server would also track the timer for the session, when the timer expired it would send a response to all the clients, as well as ignore any later answers. A round integer could be stored in the session, and wrapped in communication with sessionID so as to differentiate answers to past questions. You could have a timer for prediction on the client, but the server needs to be the authority over the timer to avoid cheating.
Use secure ssl https protocols using your own auth tokens to keep the cheaters out.
The client would need to keep track of time span for each player not the actual time. The individual times spans are sent to the server after the round ends on each client.
Think of it like this. There are 3 clients, all polling a server as when they start the round. Because the three could have varying network speeds you don't know who will actually start first. So when each client finally receives the green light then the timer starts for that device, on that device at that time it is received on that client device. You wait until all 3 report back to the server with their time spans to determine who won the round.
There as some topics of concern out of the logic of just the game. Here are some examples.
User Identity and Authorizing. (Game Center)
Game Data Persistence and Storage. (Cloud Database like AWS DynamoDB)
Game Match Queuing. (AWS SQS) Don't attempt this with a database using pessimistic concurrency.
Notifications of Match Players are ready for sleeping clients. (AWS SNS to APNS to Endpoint(this mobile device))
Polling or Notification for Next Move. (AWS SQS or SNS) I wouldn't poll the Database.
Those services are just example recommendations. I don't work for Amazon, they are the easiest to get up and running but there maybe better services out there.
Basically what I am getting at you are going to want more than a traditional MySQL database on some basic hosting site. Some of these cloud services have become very affordable as compared to creating all the infrastructure yourself on dedicated servers.
The are exponentially more scalable also.
You could do all that listed above to start out for under $15 a month using cloud services. The best thing is if your idea takes off you simply bump up the thresholds on those with a flick of a switch from an admin portal.
That would be a good problem to have.
I'm currently designing an application for iOS (using MonoTouch) that will have a server component running on Windows Azure. The application will essentially be a chat type application where users will generate messages within their clients and send them to the server, which will then need to forward those messages out (as quickly as practicable) to other clients that the user might be sending the messages to.
My question is - is there a recommended practice for architecting an application like this, where clients need to receive 'push' messages from the server?
I've considered a few options but would appreciate feedback.
The first option is to use Apple's Push Notifications service (APNs). I have two concerns about this - first, the clients only need to receive the messages when they're online (APNs sends messages through when the app is closed too, which I don't need or want); and second, there is a possibility that there will be a high volume of messages, which I know Apple would probably get unhappy about (perfectly fairly).
A second option I considered is using a web service (WCF-based) and having the client call this service every (say) 2-3 seconds, which is the maximum delay we could tolerate. This would seem to involve a great deal of potentially unnecessary network traffic, though ("have you got anything for me?", "no", repeated ad nauseum).
A third option is to maintain a persistent web service connection between the client and the server. When the client app starts it would call a web service method on a background thread. The server would hold the connection open (by not returning anything), and if any messages came through it would immediately return them. This connection might time out after, say, 2 minutes at which point it would be re-established. This seems to do what I want, but again, I'm concerned that there'd be a lot of connections open to the server at any moment, which could require server resources unnecessarily.
A fourth option is to use a persistent connection over TCP (or UDP, although from what I've found, Windows Azure doesn't support this). This seems to be a good option, but again, might be overkill in terms of server usage - there could potentially be hundreds or even thousands of clients connected at any moment.
A fifth option is to somehow have the server push messages directly to the client, perhaps by having the client run a mini web server or similar. However, as the app will be running on 3G and WiFi networks (beyond my control) I don't expect incoming ports will be open for this sort of thing.
If anyone has any other suggestions, or thinks one of the above options would be a good idea (or is a standard way of approaching this sort of problem) I'd be very interested to hear about it.
Thanks in advance,
John
You had a look at Pubnub http://www.pubnub.com/ ?