Jump to content

  • Log In with Google      Sign In   
  • Create Account


Disadvantages of P2P in my situation?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
16 replies to this topic

#1 Chris Reynolds   Members   -  Reputation: 110

Like
0Likes
Like

Posted 02 September 2009 - 03:05 PM

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

Sponsor:

#2 Atrix256   Members   -  Reputation: 510

Like
0Likes
Like

Posted 02 September 2009 - 03:16 PM

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 (:

#3 Antheus   Members   -  Reputation: 2397

Like
0Likes
Like

Posted 02 September 2009 - 03:17 PM

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.

#4 hplus0603   Moderators   -  Reputation: 5163

Like
0Likes
Like

Posted 02 September 2009 - 03:23 PM

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.


#5 Chris Reynolds   Members   -  Reputation: 110

Like
0Likes
Like

Posted 02 September 2009 - 04:46 PM

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.

#6 0BZEN   Crossbones+   -  Reputation: 2013

Like
0Likes
Like

Posted 03 September 2009 - 12:48 PM

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.

#7 Chris Reynolds   Members   -  Reputation: 110

Like
0Likes
Like

Posted 03 September 2009 - 02:09 PM

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.

#8 Codeka   Members   -  Reputation: 1157

Like
0Likes
Like

Posted 03 September 2009 - 02:13 PM

Quote:
Original post by Chris Reynolds
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.
That's a good initial solution.

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".

#9 hplus0603   Moderators   -  Reputation: 5163

Like
0Likes
Like

Posted 03 September 2009 - 04:15 PM

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.


#10 Ravyne   Crossbones+   -  Reputation: 7116

Like
0Likes
Like

Posted 03 September 2009 - 04:35 PM

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.

#11 wodinoneeye   Members   -  Reputation: 748

Like
0Likes
Like

Posted 04 September 2009 - 08:48 AM

One problem with clients is how much resource they have left over after running glitzy graphics and other input/output related tasks.

Many games have a fairly light load for the simulation (mainly just bookkeeping and simple math/logic to resolve interactions, and even the 'AI' is barely much of anything -- though a game with alot of pathfinding can require more than a little)

8-way intercommunication probably wont be too bad N^2 with constant connections (more complex P2P schemes for masive worlds would start having overhead for the connect/disconnect/boundry transition operations/interactions and that bothersome tendency for players to all be in the same place overloading the 'server' running that location)

As AI gets more complex it will start eating alot more CPU/memory resources and probably a broader information window (pulling alot of data constantly between the P2P distributed servers). That is one situation where a tight server cluster has advantages.

They will be having the multi/many core processors available to provide increased CPU capacities, but a small increase in the AI ability uses magnitudes more CPU so I dont much expect more complex AI in the near future. Eventually that CPU requirement may require a 'cloud' of peers to run AI for NPCs effectively acting just like the players client (except without the graphics) running simultaneously.

The network data feed would then only be a linear multiplication of whats currently used (unless the games get alot 'richer' with more detail events, then it will be a multiplier of that)





#12 Chris Reynolds   Members   -  Reputation: 110

Like
0Likes
Like

Posted 04 September 2009 - 11:06 AM

Would it be correct to determine each client's average ping at the time of game initiation, and the client with the lowest ping will become the server?

And then if that client cannot be punched through, try the next client down on this list..

#13 Antheus   Members   -  Reputation: 2397

Like
0Likes
Like

Posted 04 September 2009 - 11:52 AM

Quote:
Original post by Chris Reynolds
Would it be correct to determine each client's average ping at the time of game initiation, and the client with the lowest ping will become the server?


It's about the same as asking whether looking at current temperate is a good way to decide how to dress over entire year.

On internet, each packet is completely independent of all others, regardless of protocol.

Another issue is that to determine who should become the server would require peer-to-peer analysis of network conditions, or n*(n-1) individual connections, without equivalence condition being true (asymmetric connections, varying load, ISP buffering, and all other annoyances). In other words, it's just barely better than picking out one at random.

A client might work great 95% of the time, but would get stalled the remaining 5% for several seconds, or just have high jitter overall. Pathping, for example, runs for several minutes to get statistical estimate of network conditions over that time.

#14 0BZEN   Crossbones+   -  Reputation: 2013

Like
0Likes
Like

Posted 04 September 2009 - 02:04 PM

You're just better of letting players host games on their own. If they are hard to reach, they just wont get anyone connecting.

When you host a game and advertise yourself to the lobby server, the lobby server can detect if your host has good NAT punchthrough capabilities (port is forwarded correctly, ect...), and send a warning message back if not. Then the user can setup his router accordingly.

#15 Chris Reynolds   Members   -  Reputation: 110

Like
0Likes
Like

Posted 04 September 2009 - 02:38 PM

Ok, thanks for the replies, very helpful.

I have decided now to allow users to host there own servers, only after being screened for NAT punchthrough type from the server to make sure users can connect to them.

But I would also like to let other clients in the lobby see what connection type or speed the host has. Is this possible?


#16 0BZEN   Crossbones+   -  Reputation: 2013

Like
0Likes
Like

Posted 04 September 2009 - 03:43 PM

Host connection speed is a bit tricky. You can get the latency between the host and the lobby server easily, but its actual upstream capability is not straight forward.

The XBox has a bandwidth evaluation API, but that's tightly regulated (to avoid D.O.S. attacks and the likes). You usually run it once. The client can also run a NAT check himself, store his NAT performance result, and return the hosting capabilities to the lobby servers as part of the public session parameters. For example, I know that COD4 and Halo 3 will complain if your router is too strict. And clients with strict servers will only be able to join open game sessions (they use three levels, STRICT, MODERATE, and OPEN).

so, both the game hosts and game clients will have a known NAT level, you can basically restrict the games you can join like so


can we join the host session?
-----------------------------

host OPEN MODERATE STRICT

client
OPEN yes yes yes

MODERATE yes yes no

STRICT yes no no



Another thing that's often used is QoS queries between a client and a potential game host.

A QoS query is basically the client requesting a packet (like a ping request) from each game hosts directly. That stresses the NAT punch-through and also makes sure a host is actually present and responding. A host may stop responding for example, if he crashed, while he may still be registered on the lobby server.

A QoS request can give a better approximation of the latency between a host and a client, and also, the QoS packet could contain some useful custom information about a game, like the number of players in the game, the game remaining time. Custom stuff that are not vital to the matchmaking but can be useful information for clients.

Take for example Counterstrike:Source.

first, you query the lobby server for a list of games, with a list of filter settings as an argument.

Then The lobby server returns you some games currently running. Some basic information will be returned, such as the game map, the free slots, the player limit, the server name, address, session id, ect...

Then, on the client side, for each games returned by the server, you issue a QoS request to the game hosts, to get some more accurate information (NAT level, return-trip latency, which custom mods are running, list of players in the game with their scores, playing time, and so on).

Theoretically, the lobby server could return only the minimum information required for a client to join a game (host public address, session id and session key). The rest of the parameters can be discovered via a QoS request with the game host (game name, game map, game type, number of players, number of free slots, ect...). That would move some of the load from your lobby server onto the game hosts themselves. Although the savings are pretty minimal, a lobby server will have to deal with thousands of queries so it all adds up.

#17 Chris Reynolds   Members   -  Reputation: 110

Like
0Likes
Like

Posted 04 September 2009 - 05:04 PM

Thank you very much for your help. I'm going to implement the QoS query to ensure reliability. However, my game specifics don't go any further than number of players and game type, so I'm going to continue querying the lobby server for those values




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS