Disadvantages of P2P in my situation?
Author
I'm working on a 2d game that will have no more than 8 people in a single game.
What are the disadvantages of connecting all peers to eachother, rather than having a governing server? I am doing this as to not have to have a dedicated server to host everyones games on ;)
I have a lobby server that matches people up with eachother, then I want the clients to be taken off the server and connected to eachother in order to play the game.
I have it set up with 2 players, and it works well, but I'm worried about two things.
1.) With 8 players, possibly from different places around the world, will this greatly impact lag? How does having a central server help in this sense?
2.) To prevent cheating, clients can check if packets have been tampered before being received. So other than this, is a server necessary to monitor gameplay?
Thanks in advance for any help
Well P2P is more difficult to program in this kind of a setup because all 8 people have to share information with all the other people, and you have to make sure all the information stays synchronized and that it's all correct.
Whenever there's a discrepancy you'll have to do something like figure out what most people are saying is right and use that (like if 6 people say X=5 and 2 people say X=7, you should trust that X=5).
What you might want to do is if there's a game with 8 players, one of them is the server, and the other 7 are clients.
If the person that is the server leaves the game you could then choose another person to be the server.
Thats generally what games of your type do I believe (:
Whenever there's a discrepancy you'll have to do something like figure out what most people are saying is right and use that (like if 6 people say X=5 and 2 people say X=7, you should trust that X=5).
What you might want to do is if there's a game with 8 players, one of them is the server, and the other 7 are clients.
If the person that is the server leaves the game you could then choose another person to be the server.
Thats generally what games of your type do I believe (:
Down this forum, there are two locked threads, in which the downsides of P2P have been broadly discussed.
That said - if you do the math right, if you properly estimate your user's connection types, and if server correctly implements all the tiny gotchas, from NAT handling over reliability to extrapolation and asynchronous nature, then P2P might offer some advantages for small player numbers.
That is a lot of ifs, and most developers came to conclusion that total cost of hosting a central server (as well as offering some other benefits), outweighs the complications of P2P.
As said, a lot of ifs, and only for small n.
That said - if you do the math right, if you properly estimate your user's connection types, and if server correctly implements all the tiny gotchas, from NAT handling over reliability to extrapolation and asynchronous nature, then P2P might offer some advantages for small player numbers.
That is a lot of ifs, and most developers came to conclusion that total cost of hosting a central server (as well as offering some other benefits), outweighs the complications of P2P.
As said, a lot of ifs, and only for small n.
Q: I don't want to have to buy servers for all my players, so I'd like to use peer-to-peer for my 8-player games. Is that a good or bad idea?
A: Note that client/server doesn't generally mean that you need to pay for a central server (other than lobby server, which you need in either case).
In most cilent/server games, one player will "host" a game, and other players will "join." That player will then be the "server" and the other players the "clients." This means that everyone send their commands to the host, and the host sends a copy of everyone's commands to everyone.
In a true peer-to-peer topology, everybody sends their commands to everybody else, so no one machine is the "host" or "server."
Let's consider the amount of bandwidth used, with some assumptions:
State/command record/framing per player per tick: 24 bytes.
Protocol framing overhead per packet (clock etc): 8 bytes.
UDP overhead per packet: 28 bytes.
Send rate: 20 packets per second.
When I say "server" I really mean "hosting client."
Client/server client:
Send: 20 * (28 + 24 * 1 + 8): 1200 bytes/sec
Receive: 20 * (28 + 24 * 7 + 8): 4080 bytes/sec
Client/server server:
Send: 20 * 7 * (28 + 24 * 7 + 8): 28560 bytes/sec
Receive: 20 * 7 * (28 + 24 * 1 + 8): 8400 bytes/sec
Peer/peer node:
Send: 20 * 7 * (28 + 24 * 1 + 8): 8400 bytes/sec
Receive: 20 * 7 * (28 + 24 * 1 + 8): 8400 bytes/sec
You will note that every node will send a lot less data when the nodes are clients. This is important because upload is typically a lot more limited than download on DSL/cable connections.
You will also note that overall network bandwidth consumed is a lot less in the client/server case.
For peer/peer nodes, because everyone sends an equal amount, the uplink rate of the slowest peer will determine quality of gaming.
Finally, you will note that the poor server will receive as much as any peer/peer node, but it will send more than that. Thus, in C/S, the upload rate of the server will determine quality of gaming.
It is generally easier to find one node with decent upload bandwidth (to act as the host), than to make sure that everyone has sufficient upload in the peer/peer situation.
Finally, if you worry about NAT punch-through or firewall port forwarding (which you generally want to), then EACH peer node needs to have a port forwarded, or have a firewall/router that allows NAT punch-through. As soon as one node doesn't support that, that node cannot play. With a client/server approach (user hosting), then only the hosting/serving user needs a port forwarded, and/or NAT punch-through to work.
No matter what you do, you won't get away from needing a lobby server, and generally you will want this lobby server to also do NAT punch-through introduction, which means that basing the lobby server on a "free web host" (or any web-server based solution) won't actually work. In the end, if you want to run a good quality networked game, you'll need to keep some kind of machine always online, running a process that's specific to your game.
A: Note that client/server doesn't generally mean that you need to pay for a central server (other than lobby server, which you need in either case).
In most cilent/server games, one player will "host" a game, and other players will "join." That player will then be the "server" and the other players the "clients." This means that everyone send their commands to the host, and the host sends a copy of everyone's commands to everyone.
In a true peer-to-peer topology, everybody sends their commands to everybody else, so no one machine is the "host" or "server."
Let's consider the amount of bandwidth used, with some assumptions:
State/command record/framing per player per tick: 24 bytes.
Protocol framing overhead per packet (clock etc): 8 bytes.
UDP overhead per packet: 28 bytes.
Send rate: 20 packets per second.
When I say "server" I really mean "hosting client."
Client/server client:
Send: 20 * (28 + 24 * 1 + 8): 1200 bytes/sec
Receive: 20 * (28 + 24 * 7 + 8): 4080 bytes/sec
Client/server server:
Send: 20 * 7 * (28 + 24 * 7 + 8): 28560 bytes/sec
Receive: 20 * 7 * (28 + 24 * 1 + 8): 8400 bytes/sec
Peer/peer node:
Send: 20 * 7 * (28 + 24 * 1 + 8): 8400 bytes/sec
Receive: 20 * 7 * (28 + 24 * 1 + 8): 8400 bytes/sec
You will note that every node will send a lot less data when the nodes are clients. This is important because upload is typically a lot more limited than download on DSL/cable connections.
You will also note that overall network bandwidth consumed is a lot less in the client/server case.
For peer/peer nodes, because everyone sends an equal amount, the uplink rate of the slowest peer will determine quality of gaming.
Finally, you will note that the poor server will receive as much as any peer/peer node, but it will send more than that. Thus, in C/S, the upload rate of the server will determine quality of gaming.
It is generally easier to find one node with decent upload bandwidth (to act as the host), than to make sure that everyone has sufficient upload in the peer/peer situation.
Finally, if you worry about NAT punch-through or firewall port forwarding (which you generally want to), then EACH peer node needs to have a port forwarded, or have a firewall/router that allows NAT punch-through. As soon as one node doesn't support that, that node cannot play. With a client/server approach (user hosting), then only the hosting/serving user needs a port forwarded, and/or NAT punch-through to work.
No matter what you do, you won't get away from needing a lobby server, and generally you will want this lobby server to also do NAT punch-through introduction, which means that basing the lobby server on a "free web host" (or any web-server based solution) won't actually work. In the end, if you want to run a good quality networked game, you'll need to keep some kind of machine always online, running a process that's specific to your game.
Author
Thanks for all the replies, very useful information..
I am planning on hosting the lobby server on my own machine, but did not want to host the games on my machine as well.
My current setup is like this: Clients connect to server, server tells both clients to accept talking to eachother so the NAT punch through happens while the clients are connected to the server.
I guess I will try the "serving client" method if my current methods isn't efficient.
I am planning on hosting the lobby server on my own machine, but did not want to host the games on my machine as well.
My current setup is like this: Clients connect to server, server tells both clients to accept talking to eachother so the NAT punch through happens while the clients are connected to the server.
I guess I will try the "serving client" method if my current methods isn't efficient.
one big problem is when a peer cannot connect to another peer (due to router issues mostly). Then you have to decide to either kick one of the peer (the last one to join usually), or forward packets to that peer via another client (or the host).
If you don't have to do peer to peer, don't do it, it just complicates everything. With 8 players, the game host should be able to broadcast everything he needs to the 7 clients with a reasonable network load. The lower p2p latency is really not worth the trouble imo.
If you don't have to do peer to peer, don't do it, it just complicates everything. With 8 players, the game host should be able to broadcast everything he needs to the 7 clients with a reasonable network load. The lower p2p latency is really not worth the trouble imo.
Author
Quote:Original post by oliii
If you don't have to do peer to peer, don't do it, it just complicates everything. With 8 players, the game host should be able to broadcast everything he needs to the 7 clients with a reasonable network load. The lower p2p latency is really not worth the trouble imo.
If the "serving client" doesn't have that great of a connection, is it going to impact a 2d game with only 8 players at a time to a degree that it would be smarter to host a dedicated server for the players? Hosting a dedicated server would likely mean the difference between my game being free and costing money :(
The game has to be initiated by someone, so maybe I'll give a prompt that warns users that the game initiator needs a good connection speed.
Quote:Original post by Chris ReynoldsThat's a good initial solution.
If the "serving client" doesn't have that great of a connection, is it going to impact a 2d game with only 8 players at a time to a degree that it would be smarter to host a dedicated server for the players? Hosting a dedicated server would likely mean the difference between my game being free and costing money :(
The game has to be initiated by someone, so maybe I'll give a prompt that warns users that the game initiator needs a good connection speed.
Perhaps a feature you could think about would be transferring the duties of "host" to whichever player has the best connection. This is a little more complicated, but basically when you connect to the lobby, each client could give some sort of indication of it's connection speed to the lobby server, so that when all players are ready to start, the lobby server could simply nominate the player with the best connection as the "server".
Gamers generally know what it means to "host" a game, and that they need a good network connection. This is how it's almost always done in most online multiplayer games that aren't "MMO." -- Quake, Counter-Strike, HALO, etc all do that.
I hear that MAG won't, though -- they'll host servers for free for anyone who buys the game. That will be interesting.
I hear that MAG won't, though -- they'll host servers for free for anyone who buys the game. That will be interesting.
I say the best solution is to host your matchmaking/lobby server, and choose one of the players to host -- this is exactly how all of Xbox live works, save the very few games with dedicated hosts (MMOs, etc).
I would impliment as part of your matchmaking protocol that the matchmaking server can ask each client to initiate a connection with a list of IPs and report back the latency. Then, you can allow the clients to request a certain set of game options they desire, pass them back a list of IPs from people looking for a similar game types, and then use that information (and the info collected from the other clients) to recommend a set of games with strong connections -- finally, you may wish to give them the option to hold out for an exact match, and to host a game on a friends/invite-only basis.
I would impliment as part of your matchmaking protocol that the matchmaking server can ask each client to initiate a connection with a list of IPs and report back the latency. Then, you can allow the clients to request a certain set of game options they desire, pass them back a list of IPs from people looking for a similar game types, and then use that information (and the info collected from the other clients) to recommend a set of games with strong connections -- finally, you may wish to give them the option to hold out for an exact match, and to host a game on a friends/invite-only basis.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
