Quote:Original post by hplus0603
Actually, almost no PC game is Peer-to-peer. While some games allow users to host without a central server, that merely means that the user doing the hosting is the topological server. Starcraft, for example, is explicitly *not* a peer-to-peer game.

Quote:absolute optimisation and lowest possible hardware requirements

I understand engineering. what I'm trying to say is that those two requirements are actually contradictory in certain terms. If you want the lowest possible latency at all costs, then that's not optimization, because the overall total cost goes up -- you require everyone to have a great Internet connection. Engineering is the art of making smart trade-offs to deliver the most end user value at the lowest possible cost. Low latency is "value," high bandwidth requirement is "cost." Bandwidth might also be considered a "hardware requirement," so reducing bandwidth means reduced hardware requirements.

If you're really into P2P networking for games, I suggest you check out the VAST project (a link to which is in the Forum FAQ).

ok, i think it's safe now to conclude that p2p multiplayer is non-existent or at least very rare.

yes, actually it is contradictory, i agree. so, to put it more precisely - from the algorithm and software implementation point of view, as a programmer, im after speed - fast code, but in the terms of network architecture i'm interested in _theoretically and _potentially faster solution. in theoretical terms, i expect the future to get rid of the limits current network and other information infrastructures pose... so, simply said, without client upload speed limit i see no way server model would outperform p2p, and even now, as it is today, p2p might be very well suitable candidate to replace server based model for some specific, if not most, situations. i kind of have a feeling it's the 'security' what made and keeps p2p so wildly unpopular.

thanks for that link, that's exactly what i was looking for... if anyone can find more such projects feel free to let me know.

Quote:Original post by Antheus
Here are some numbers: 7, 22, 45, 88, 102, 344.

Actually, the real ones are below:

Quote:this situation can change rapidly as number of clients increases,

The total number of packets in the network increases with n squared. So with 2 clients, there are 4 packets. With 16 clients, there are 256 packets. With 100 clients, there are 10,000 packets. Sent 60 times per second.

To be completely fair, the number is n*(n-1), but for the purpose of this discussion, this doesn't matter beyond 3 clients.

Quote:"upload", does that mean top speed would be limited by client ISP's upload speed limit?

Yes. Or better yet, by each user's subscription plan's limit (128kbit - several Mbit).

Quote:this is where server model might catch up, if not overrun p2p, i think... since the difference in upload/download speed is so great for most of the ADSL plans, as far as i know. any thoughts on this?

Due to wonders of mathematics, we can determine when this would happen. The formulas are given above. For each update (60 times per second)

Server client
Server: N packets
N * Each client: 1 packet
Total number of packets: N + N

P2P:
N * Each client: N packets
Total number of packets: N * N

As far as number of packets goes:
N * N < N + N
N^2 < 2N
N < 2

In other words, P2P is only more efficient as long as there are at most two peers.

When there are 3, P2P needs to generate 9 packets, C/S only 6. When there are 64 clients, P2P needs to generate 4096 packets, while C/S only 128.


Bandwidth requirements, 64 players
P2P:
Each player sends 10 bytes (+28 bytes packet overhead), 60 times a second, to 64 peers. This adds up to 38*60*64 bytes per second, or 145920 bytes per second. So each player needs to have ~1.2Mbit upstream.

S/C:
Each player sends 10 bytes (+28 bytes packet overhead), 60 times a second, to server. This adds up to 38*60*1 = 2280 bytes per second, or approximately 20kbit upstream (a dial-up modem provides it).
Server however, needs to send full updates, at maximum rate same as P2P (often less), so ~1.2Mbit. Servers are typically hosted by operators in data centers, not in bedroom computers.

But it gets worse. For each update, all of those packets are send over internet. The total bandwidth required by each model is:
P2P:
Each client sends to all others, so 1.2MBit * 64 = 76.8MBit
S/C:
1.2Mbit + (64 * 0.02Mbit) = 2.48Mbit


But now lets look at 256 player game:
P2P:
38*60*256*256 = 1.14 Gigabits
S/C:
38*60*256*2 = 8.9 Mbit

Let's go further. On WoW server, there are about 3000 at any given time (except Tuesdays).
P2P: 38*60*3000*3000 = 152 Gigabits (152,000 Mbits)
S/C: 38*60*3000*2 = 104 Mbits (or the capacity of home broadband router)
And this is just for a single shard - WoW has how many, hundred?

See the problem with P2P, and why just a simple napkin calculation shows it simply doesn't work?

Just because The Cloud is somewhere out there, it doesn't mean it's magic infinite space. The numbers listed above are the infrastructure requirements, which exceed total internet capacity of most countries.

Edit: Software prefers bytes, but network gear prefer bits. So when talking about capacities, I multiply the bytes sent by 8 to obtain bits. Not entirely correct, but close enough - it's not what makes or breaks it.

beautiful!
thank you, i very much appreciate that.

i'm stupid for that kind of thing and i had to see some numbers to be able to grasp it and have some picture about relations. now, let me chew on that for a while...

Quote:
When there are 3, P2P needs to generate 9 packets, C/S only 6. When there are 64 clients, P2P needs to generate 4096 packets, while C/S only 128.

emmm...is that per client, per whole network, upload, download?

that doesn't seem right, this is how i see it:

- per one frame, per one client -
*** 3 clients:
p2p-model upload: 2
p2p-model download: 2
total: 4

server-model upload: 1
server-model download: 3
total: 4


*** 6 clients:
p2p-model upload: 5
p2p-model download: 5
total: 10

server-model upload: 1
server-model download: 6
total: 7


*** 64 clients:
p2p-model upload: 63
p2p-model download: 63
total: 126

server-model upload: 1
server-model download: 64
total: 65


do we understand each other?
are we talking about same stuff here?

Quote:Original post by gbLinux
beautiful!
thank you, i very much appreciate that.

i'm stupid for that kind of thing and i had to see some numbers to be able to grasp it and have some picture about relations. now, let me chew on that for a while...

I edited the post so the wording is incorrect. The numbers are overhead and wasted bandwidth, not actual requirements.

Or simply put, a user with 1Mbit upstream would not have enough spare bandwidth to send anything. If you actually send the data, things get worse.

If all clients are sent full updates, then P2P and C/S need about the same bandwidth. But P2P has so much more overhead.

A user participating in 64-player P2P game over 1Mbit upstream would waste their entire bandwidth on packet overhead, and couldn't even send any usable data.

Quote:Original post by gbLinux

*** 64 clients:
p2p upload: 63
p2p download: 63
total: 126

*Each* client. You listed one. There are 64, and each needs to send 63 packets. So each update generates 4032 packets in the internet.

Quote:emmm...is that per client, per whole network, upload, download?

Per entire shared state. Per game. That is total across all servers and all clients.

In P2P, there are a total of 64 clients, each of them generates 63 packets it sends to all others.
In C/S, each client sends one packet to server, and server sends on packet to each client.

Quote:

Quote:Original post by gbLinux

*** 64 clients:
p2p upload: 63
p2p download: 63
total: 126

*Each* client. You listed one. There are 64, and each needs to send 63 packets. So each update generates 4032 packets in the internet.

i said per ONE client, per ONE frame... why do you care how much you saturate WWW in general? that does not influence latency, individual bandwidth or speed of p2p network in any way i can perceive. what does it matter? isn't that like if everyone started talking faster over the phone? would that "overload" the lines, slow down internet or something?

Quote:

Quote:emmm...is that per client, per whole network, upload, download?

Per entire shared state. Per game. That is total across all servers and all clients.

In P2P, there are a total of 64 clients, each of them generates 63 packets it sends to all others.
In C/S, each client sends one packet to server, and server sends on packet to each client.

i'm afraid the information server sends to each client about each other client is much bigger than what clients send to server and what peers send to peers in p2p.

it's more realistic to say that in C/S each client send one "packet" and receives as many "packets" as there are other clients, or in the worse case as many as there are dynamic entities of any kind in the client scene.

we should only be concerned about upload/download stream per ONE client, not about some "internet saturation", unless someone can explain how that matters.

Quote:
If all clients are sent full updates, then P2P and C/S need about the same bandwidth. But P2P has so much more overhead.

A user participating in 64-player P2P game over 1Mbit upstream would waste their entire bandwidth on packet overhead, and couldn't even send any usable data.

well, i can't trust if you're using right numbers and formulas again. are you saying they would use alloted ammount of download data pemited by ISP, or that their UPLOAD SPEED would not be sufficient?

so, i suppose server-based games host 64, maybe more players? what is the maximum number of players allowed per server on some of the most popular games?

Quote:Original post by Matias Goldberg
Hi!

Quite an argument here.

I just wanted to point about the ABC problem. I'll change it to:

*** Source Snippet Removed ***

AD = DC = 30km.
SD = 17km

Server approach:
Info comming from B to D needs 34km

P2P approach:
Info comming from B to D needs 60km

that seems wrong. those numbers were not coincidental, that's what you get with equilateral triangle on a flat surface and it's centre, you can't just imagine numbers... or perhaps you can, but that makes for distorted geo-surface. here is how it goes for equilateral quadrilateral, such as square and rhombus.

B            C      s       30km  20kmA            D

AB=BC=CD=DA = 30km
As=Bs=Cs=Ds = 20km

*** P2P, one frame loop, per ONE client
round-trip: ~33km (2x 30km, 1x 40km)
packets sent: 3
packets received: 3
total packets per client: 6

*** SERVER, one frame loop, per ONE client
round-trip: 40km
packets sent: 1
packets received: 4
total packets per client: 5


it cant' get better than this for server-based model, having server in the middle... it's only client's upload speed limit that can make server based model faster, as far as i can see.

i just realised i was mixing two concepts.

it is important to differentiate line Speed and Bandwidth. even tho referred to as a "speed" bandwidth is actually not what matters to "PING", it does not measure the speed with which packets travel or influence how long would it take to arrive at destination... for that we need some distance and the number of routers and checkpoints it must stop and visit on the way.

say, if the speed of water molecules in some water-pipe is what packet speed is in network lines, then bandwidth is the width of that pipe, ie. how many packets can flow through it per second. but the speed, the speed is always about light speed, i suppose, minus all the time lost in routing... and that's pretty much all i know about this. what routers do and how much they slow packets down, that i don't know.


anyhow, this is what is important:
- if SPEED is the same for upload and download (forget bandwidth) between peers in p2p as it is between server and clients, than p2p simply must be that much faster (as explained with ABC). bandwidth only starts to matter with more with, say 16 or 32 players, and even than it heavily depends on just how much you can squeeze your communication info, so 32 players on p2p sounds quite doable with average ADSL connections.



the conclusion:
p2p game with 8 or less players must, simply must be faster than server-based game, given the same hardware and having some average ADSL connections. does anyone wanna challenge this conclusion?



btw,
the only thing i could google about "p2p multiplayer" is that some folks are complaining about some "laggy Xbox 360 P2P multiplayer", whatever is that all about, plus some mobile games are using it via bluetooth.. that's pretty much all. how peculiar. and, what now... hopefully someone will refute my conclusion so i don't have to be the one to produce the first online p2p multiplayer game in the world.

[Edited by - gbLinux on August 29, 2009 2:35:08 AM]

Quote:I think it's already been establed that a "peer to peer" model is only useful if all the clients are geographically close (otherwise latency is unavoidable, and the latency of Sydney-LA, say, far outweighs any latency a server may introduce).

i'm pretty sure this has not been established, in fact most of the stuff said here is pretty vague or was refuted by subsequent posts. we didn't even know if p2p multiplayer games were very common or very rare, even now i'm not quite sure about it... hahaa. anyhow, set any example you want pick any cities you want and we will calculate traversal for both models, i assure you latency will be LESS with p2p as long as bandwidth does not come into play.

btw, does anyone know about this Xbox 360 p2p network?

The very last piece of help I can offer:

+-----------+|   Brick   |+-----------+

Apply liberally to forehead until enlightened.

Considering physics background, this is equivalent to trying to design Carnot engine with efficiency above 1.

The most fundamental concepts state it cannot be done, yet many people still try to develop perpetuum mobile, hoping for a miracle.