Archived

This topic is now archived and is closed to further replies.

Wormhole

P2P Internet Multiplayer

Recommended Posts

I''ve seen lots of stuff about client/server multiplayer. Peer-to-peer looks interesting, tho. Would anyone know where I might be able to find resources about developing internet-based multiplayer games using P2P? Does anyone have any thoughts on P2P or what it could mean for gamers (besides downloading a free copy of the game off gnutella, cmon)? thanks ------======||||||EEEEEEE*<

Share this post


Link to post
Share on other sites
quote:
Original post by Ixpah
Do a search of this forum, this topic has been discussed a few times.


The discussions are interesting, but they seem a little too specific or a little too much like arguments to be really useful at this point. I''m not necessarily talking about any specific kind of game being implemented with P2P. I''m talking very general here.

quote:
Original post by Ixpah

NAT, security, latency, and bandwidth will be your big problems using this model.


Okay, maybe it''s just because I haven''t read too many books on networking just yet, but I have no idea what the hell NAT means. Please define and elaborate.

Security is always a concern - it doesn''t matter whether you''re using P2P, Client/Server, a genie in a bottle, or a bunch of hamsters to run something over the internet. I''m wondering what existing P2P networks like gnutella and limeware do about security?

Lag sucks. How do you get rid of it? It seems like it''s really tied in with bandwidth, am I right? you know, more bandwidth = less lag.


------======||||||EEEEEEE*<

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
While its easy to see where you get the more bandwidth/less lag association this is not the case. It just happens to be that a higher bandwidth connection usually has less lag. A counter example of this would be a high speed sattelite connection. You can get download speeds that rival any other high speed connection, but because of the distance (and perhaps some other factors) you get horrible "lag".

Share this post


Link to post
Share on other sites
Right, and as such, lag is much more commonly associated with stuff that''s not even related to the game itself.

Found a somewhat dated, but relevant rant on this:
http://www3.sympatico.ca/glacier/pf140398.htm


Technical nitpicking aside, a peer-to-peer network is very, very different from a client/server network and is going to be better at some things and worse at some others.

i.e. Imagine a game network that instantly gave you access to every custom map ever made for that game. P2P would be fantastic for something like this.

That''s just the beginning.

Using P2P to handle multiple real-time connections presents lots of problems. The lag issues discussed in the above mentioned article affect everyone else''s ability to operate instead of just the server''s. Good client-side connections are absolutely more important than ever in a real time P2P network.

------======||||||EEEEEEE*<

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Upstream bandwidth is a huge problem with this model. Instead of sending updates to one location (the server) each client has to send it''s updates to all the other clients.

When you couple that problem with the fact that clients typically have less upstream bandwidth than downstream, you start to realize why most network games these days are client-server...

Share this post


Link to post
Share on other sites
NAT (Network Address Translation).
Often people connect through a proxy/NAT router. What this means is they don''t have a Internet usable IP address, so they can only initiate connections.

Bandwitdh/Lag
Even though ADSL/Cable has 500kB/250kB downstream/upstream bandwidth doesn''t mean that all of this is available 24/7. ADSL has contention ratios of 20:1 and 50:1 in the UK. This means that you are effectively sharing you bandwidth with 20 or 50 other poeple. Cable has similar but different restrictions.

Security
For a non-persistant world then things may not be to bad, but if its a MMORPG then you will get all sorts of hacking problems. This is due to the fact that they will get access to all of the code and data, instead of a limited subset of it in the case of a client/server system.

Share this post


Link to post
Share on other sites
quote:
Original post by Ixpah
NAT (Network Address Translation).
Often people connect through a proxy/NAT router. What this means is they don''t have a Internet usable IP address, so they can only initiate connections.

Bandwitdh/Lag
Even though ADSL/Cable has 500kB/250kB downstream/upstream bandwidth doesn''t mean that all of this is available 24/7. ADSL has contention ratios of 20:1 and 50:1 in the UK. This means that you are effectively sharing you bandwidth with 20 or 50 other poeple. Cable has similar but different restrictions.

Security
For a non-persistant world then things may not be to bad, but if its a MMORPG then you will get all sorts of hacking problems. This is due to the fact that they will get access to all of the code and data, instead of a limited subset of it in the case of a client/server system.


So far, based on what I''ve gathered from this and other discussions, is that an MMORPG is pretty much impossible to do using P2P under current technological conditions. That''s perfectly alright. I don''t want to beat a dead cat here. My goal for this discussion is to find out what kinds of games *are* possible and maybe identify a genre or two that could benefit with a P2P setup.

At this point, here''s what a P2P game might require (probably way off, so feel free to amend):
any non-player data must be static
each player must be responsible for sending updates to their state to all the other players
each player must be able to check updates from other players using the same set of rules for the entire duration of the game

------======||||||EEEEEEE*<

Share this post


Link to post
Share on other sites
I believe Battlezone 1 was a peer to peer game.

A given player sends updates for his tank and all the tanks and buldings under his direct control to all other machines.

For the most part, the client machine also decides if a weapon hits their own tanks, and guided weapons are implemented at the client level, which caused some interesting bugs:

A guided missile was fired at a tank during deathmatch.
The player evaded and passed in front of another player.
Both tanks exploded, because on both players' machines, the missile flew into and struck their tank.

Battlezone 2, however, was a client/server game. Even your own tank's position got corrected from time to time, and units you thought you blew up before would reappear because of a massive gamestate update from the server. That's part of the problem with real time 3D real time strategies. So much variation and possibility needs correction from time to time, and the false state could exist for 5 seconds or more before being corrected.

Point and click RTS's and simple FPS's generally do well online, because the RTS's are less randomized in the way they handle the units (less variation then real time 3D RTS) requiring only information about where they are going and what their target is, and FPS's don't transfer so much data across the wire.

And that's my little case study for the day.

[edited by - Waverider on August 16, 2002 3:35:07 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Just as a note (from reading the post 2 above, it seems a little this way) Using a peer-peer solution for multiplayer is in no way a new concept, it has been around as logn as networked multiplayer games have, and many many early games used peer-peer. This includes 3D shooters (such as duke nukem, doom 2) RTS''s, etc.

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
Just as a note (from reading the post 2 above, it seems a little this way) Using a peer-peer solution for multiplayer is in no way a new concept, it has been around as logn as networked multiplayer games have, and many many early games used peer-peer. This includes 3D shooters (such as duke nukem, doom 2) RTS''s, etc.


This is true, however the original poster specifically mentioned Internet-based peer to peer, which is a slightly different beast from LAN-based peer to peer.

Share this post


Link to post
Share on other sites
quote:
Original post by fingh
This is true, however the original poster specifically mentioned Internet-based peer to peer, which is a slightly different beast from LAN-based peer to peer.


There''s that whole bandwidth limitation, yes, and even that is beginning to disappear with this whole broadband thing becoming more common. Once the U.S. economy recovers from its current recession, broadband *will* become much more of a common thing than it is today. The question is really where the affordability is - to service providers who then lower their rates or to consumers having that extra $50+/month for high-speed internet.

IMHO, a big advantage that P2P could possibly have, if the right doors open up, is scalability. The one inherent thing about client/server that is, perhaps, a fundamental flaw, is that in order to be able to handle more players, someone has to physically add another server on the back end. If each player could be responsible for their own data, computations, etc, then theoretically, an infinite number of players could be playing the same game at the same time. And all that would have to be done to handle another player would be to just connect that player''s computer to the network. Of course there are numerous limitations that exist today that prevent any sane game developer from even attempting this, but maybe if we could firmly identify those limitations (as some of the other discussions on gamedev.net have when comparing P2P to client/server) and centralize that information, we could work to eliminate them. And yes, once those limitations are gone, then MMO games become a reality for P2P. (hey, desktop computers were once pipe dreams, too)

Has anyone played those P2P games that the cell phones have now? Anybody know some juicy details as to how they work? Are they any more or less flexible in terms of # of players?



------======||||||EEEEEEE*<

Share this post


Link to post
Share on other sites
One of the limitations on P2P games is bandwidth. Scalability is currently a huge issue, because P2P games simply cannot scale that well. As the number of players increase, so do the number of updates that have to be sent out(and received) by each player. For 4 or 8 player games, this isn''t too bad on broadband. As far as identifying possible solutions to this problem, simple: widespread use of multicast UDP. Unfortunately this isn''t something we''ll see for some time.

Share this post


Link to post
Share on other sites
quote:
Original post by Themonkster
could''nt you use the broadband users as supernodes and let them update greater numbers of other peers.


That gravitates towards a client/server setup.

------======||||||EEEEEEE*<

Share this post


Link to post
Share on other sites
quote:
Original post by fingh
One of the limitations on P2P games is bandwidth. Scalability is currently a huge issue, because P2P games simply cannot scale that well. As the number of players increase, so do the number of updates that have to be sent out(and received) by each player. For 4 or 8 player games, this isn''t too bad on broadband. As far as identifying possible solutions to this problem, simple: widespread use of multicast UDP. Unfortunately this isn''t something we''ll see for some time.


What is the order of magnitude for having n players on current P2P implementations? Are there implementations that I can have a look at?


------======||||||EEEEEEE*<

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
O(n) updates have to be sent from a single computer, O(n^2) updates are sent in total from all peers. O(n) updates are received by a single peer. Compared to a client-server where the updates for the clients are O(1) for both send and receiving, where the sent packet will be about the same size or smaller, and the received packet will likely be much larger, than a single p2p packet, but also much smaller than O(n) p2p packets. The server still has to send and receive packets on O(n).

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
O(n) updates have to be sent from a single computer, O(n^2) updates are sent in total from all peers. O(n) updates are received by a single peer. Compared to a client-server where the updates for the clients are O(1) for both send and receiving, where the sent packet will be about the same size or smaller, and the received packet will likely be much larger, than a single p2p packet, but also much smaller than O(n) p2p packets. The server still has to send and receive packets on O(n).


hmmm...you are right. The way a true p2p network is set up right now, a real-time app would almost certainly get bogged down by network traffic with any more than a few users. The reason for this is because *everyone* is a server *and* a client. Client/Server is set up so that these functions are done on seperate computers, which is sensible, but also limits the number of players in a given game to whatever the server can handle.

I''ve been thinking about this for the past hour or so, and I think I have a partial solution.

The problem here is that you''re either a server or you''re not. You either handle everybody''s crap or you only handle yours. Very Aristotlean. Let''s get fuzzy. How much of a server are you? Whose crap are you handling? Since we''re still, at least to a degree, a p2p network, everybody is at least a client. But everybody is also a server *to some degree*.

So, in order to do this, we need to figure out for each player X:
What other players is player X connected to?
What is player X responsible for sending to player Y?
What data should player X expect from player Z?

This will require a network flow problem to be solved. This can be done fairly efficiently using a bit of linear programming. Unfortunately, and this is where the solution becomes only partial, the solving of the network flow problem might not be able to be done in real time - so the network flow would have to be static. Thus, if a player drops out for some reason, the whole network is screwed. If, however, the network flow could be recomputed in dynamically - periodically or maybe even real-time - then network alterations wouldn''t pose such a problem.

Of course, the complexity of this network flow problem increases as new players are added, but I''m not sure by what degree.

------======||||||EEEEEEE*<

Share this post


Link to post
Share on other sites
quote:
Original post by Wormhole
This will require a network flow problem to be solved. This can be done fairly efficiently using a bit of linear programming. Unfortunately, and this is where the solution becomes only partial, the solving of the network flow problem might not be able to be done in real time - so the network flow would have to be static. Thus, if a player drops out for some reason, the whole network is screwed. If, however, the network flow could be recomputed in dynamically - periodically or maybe even real-time - then network alterations wouldn''t pose such a problem.



That will help out the bandwidth constraints a bit, but remember, increasing the number of hops in your network increases latency.

Why the aversion to a client server architecture?

Share this post


Link to post
Share on other sites
quote:
That will help out the bandwidth constraints a bit, but remember, increasing the number of hops in your network increases latency.



True, but the number of hops increases arbitrarily depending on how the net-flow function organizes everything. It is possible that it could be done in log(n) hops or less. It's also possible that even a few hops would severely debilitate performance.

The function I have in mind would figure the average lag between two given nodes into the system. The optimal solution it would spit out might not be optimal enough in some situations where there is just not enough bandwidth to go around or too much overall lag. Like I said, it's only a partial solution.

I seriously encourage anyone to try and think of other solutions to the bandwidth/lag problem associated with online P2P games. The solution is out there.

quote:
Why the aversion to a client server architecture?

Read the topic Line.

------======||||||EEEEEEE*<

[edited by - Wormhole on August 22, 2002 2:11:43 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Wormhole
I seriously encourage anyone to try and think of other solutions to the bandwidth/lag problem associated with online P2P games. The solution is out there.



We already did. It's called client/server! Seriously, P2P is good for file distribution because you can leverage lots of people's disks for data storage, which is more scarce than bandwidth in file distribution.

Now, look at games. Network games require three things, Processor time, RAM, and Bandwidth. Bandwidth is currently more expensive than both Processor and RAM. So, we come up with solutions to minimize Bandwidth usage at the expense of loading one machine's CPU: Client server.

Peer to Peer is good when you want to trade bandwidth for some other resource, like CPU. If/when Bandwidth becomes so great that the CPU starts becoming a bottleneck again, it makes sense to bring back P2P so we can distribute processing amongst the clients.

But currently, we've got a lot of gamers with 2+GHz processors sitting with a measily 128K DSL or cable upstream. P2P gaming just doesn't make sense given the current state of the internet. When we've got bigger upstream, or maybe IP multicast, then P2P games will come back.

[edited by - cheesegrater on August 27, 2002 11:56:14 AM]

Share this post


Link to post
Share on other sites
quote:

We already did. It's called client/server! Seriously, P2P is good for file distribution because you can leverage lots of people's disks for data storage, which is more scarce than bandwidth in file distribution.

Now, look at games. Network games require three things, Processor time, RAM, and Bandwidth. Bandwidth is currently more expensive than both Processor and RAM. So, we come up with solutions to minimize Bandwidth usage at the expense of loading one machine's CPU: Client server.

Peer to Peer is good when you want to trade bandwidth for some other resource, like CPU. If/when Bandwidth becomes so great that the CPU starts becoming a bottleneck again, it makes sense to bring back P2P so we can distribute processing amongst the clients.

But currently, we've got a lot of gamers with 2+GHz processors sitting with a measily 128K DSL or cable upstream. P2P gaming just doesn't make sense given the current state of the internet. When we've got bigger upstream, or maybe IP multicast, then P2P games will come back.



RTFTL. This is not a client/server-P2P comparison discussion. This is a (apparently dead at this point) discussion about how to improve peer-to-peer (that means NO DEDICATED SERVERS) so that it could be used on the internet either today, tomorrow, or three years from now in some form of real-time application, whether that be games or something else does not matter. At the very least, ways that P2P could be used in gaming would be great.

Solving your problems by waiting for the next toy to come around shows a serious lack of creativity that makes me wonder if you should be making games at all. What would an IP multicast system require? How could it be implemented?

I already presented a possible shortcut that would alleviate the problem of every player sending n packets every single frame. Don't be content with the answers that already exist. Originality is what drives technology forward and it stems from creative solutions to seemingly impossible problems.

BTW, I don't know if you've been reading the news at all, but John Carmack (perhaps you've heard of using BSP trees for 3D graphics?) has said that Doom 3 will use a P2P setup and will support > 4 players.


------======||||||EEEEEEE*<

[edited by - Wormhole on August 27, 2002 3:16:45 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Wormhole
RTFTL. This is not a client/server-P2P comparison discussion. This is a (apparently dead at this point) discussion about how to improve peer-to-peer (that means NO DEDICATED SERVERS) so that it could be used on the internet either today, tomorrow, or three years from now in some form of real-time application, whether that be games or something else does not matter. At the very least, ways that P2P could be used in gaming would be great.



I think it's very appropriate to bring up client server in this discussion. As the internet now stands, using P2P in a game is like pounding a square peg into a round hole. What advantages do you see in using p2p as opposed to client server?

quote:

Solving your problems by waiting for the next toy to come around shows a serious lack of creativity that makes me wonder if you should be making games at all.



Please can the personal attacks and try to keep to the topic at hand, if possible.

quote:

What would an IP multicast system require? How could it be implemented?



I could implement an IP multicast system right now. It won't work on the internet in general until it's supported on 100% of the internet's routers. Unfortunately, some largish ISPs have not chosen to upgrade yet, so the packets would be dropped on the way to some players.

This is definately the way to go for P2P in the future, since it allows you to send one packet that would reach multiple recipients.

quote:

I already presented a possible shortcut that would alleviate the problem of every player sending n packets every single frame.



Your solution was different from client server pretty much in name only. A 'supernode' system is really a set of connected client server systems. I'm not sure how this could be considered any better or worse than existing systems. I see only downside (increases hops/latency) Perhaps you could list some pros to your prosposed system as opposed to a server based one?

quote:

Don't be content with the answers that already exist. Originality is what drives technology forward and it stems from creative solutions to seemingly impossible problems.



I could accuse you of the same thing. P2P games are as old as the hills.


quote:

BTW, I don't know if you've been reading the news at all, but John Carmack (perhaps you've heard of using BSP trees for 3D graphics?) has said that Doom 3 will use a P2P setup and will support > 4 players.



Off topic, John Carmack did _not_ invent the BSP tree, nor was he the first to apply it to 3D graphics.

On topic, look at: http://firingsquad.gamers.com/features/quakecon2002/page6.asp

They haven't even *started* the Doom 3 networking code yet, so it's a bit early to talk about wether it's going to end up p2p or wether they're going to pull off a respectable player count that way.

[edited by - cheesegrater on August 27, 2002 4:28:48 PM]

Share this post


Link to post
Share on other sites