Jump to content

  • Log In with Google      Sign In   
  • Create Account

Incoming hilarity: abaraba is back, and this time he's fixated on P2P networking!


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
82 replies to this topic

#21 Jeonjr   Members   -  Reputation: 122

Like
0Likes
Like

Posted 04 September 2009 - 03:24 PM

Quote:
Original post by Andrew F Marcus
I'm sorry, but have you not in fact admitted server upload bandwidth is O(n^2) while peer upload/download bandwidth is O(n)? Do you realize how this means the same client bandwidth can allow for twice the number of players with P2P than with client-server?

...

Is it not the integrated bandwidth of O(n^2) in P2P still better than having just one client(server) use O(n^2) upload bandwidth? Does that not actually make P2P about two times more practical given the same bandwidth constraints?

I don't see how he is wrong here in the case that all clients have equal bandwidth and that if a client had to be a server.

Quote:
Original post by Andrew F Marcus
Finally, having only two-player game, do you think it would be better if one player hosted the game for both, or would P2P type of direct link turn out as a better solution in this case?

seems to be about the same but writing p2p is harder to sync.


Sponsor:

#22 Nypyren   Crossbones+   -  Reputation: 4824

Like
0Likes
Like

Posted 04 September 2009 - 03:42 PM

Quote:
Original post by Jeonjr
Quote:
Original post by Andrew F Marcus
Finally, having only two-player game, do you think it would be better if one player hosted the game for both, or would P2P type of direct link turn out as a better solution in this case?

seems to be about the same but writing p2p is harder to sync.


Another thing to consider (at least in the real world) is that companies sometimes decide it's less trouble to retrofit their ANCIENT single-player codebases so that they are multiplayer capable. This is almost impossible to do if you use peer-to-peer.

#23 hplus0603   Moderators   -  Reputation: 5729

Like
0Likes
Like

Posted 04 September 2009 - 06:30 PM

Quote:
I'm sorry, but have you not in fact admitted server upload bandwidth is O(n^2) while peer upload/download bandwidth is O(n)? Do you realize how this means the same client bandwidth can allow for twice the number of players with P2P than with client-server?


If there is no per-packet overhead, that statement would not be true, because squared and times-two are different functions.
If there is per-packet overhead, that statement would not be true, because packet overhead matters.

Do you think that the people who wrote Counter-Strike: Source, or Quake III: Arena, or Unreal Tournament, are idiots? Do you think they do not carefully test a number of different approaches before they settle on what works best? Why do you think they are not using P2P topologies?

Anyway, the proof is simple: Just write a game that is P2P and works much better than current games based on Source, Unreal, Quake etc engines. There are lots of companies out there in the games engine and middleware business, and none of them end up using P2P solutions. If you can write a much better game, or simply license a much better solution, you'll make lots of money!

I'll leave you with another question: We've all heard about MAG (Massive Actiongame), right? Do you think they use client/server, or peer-to-peer, for their 256-player matches? And why?


PS: Note that I was not the mod who banned the previous poster on the P2P topic. I believe that P2P is on topic for this forum. However, I expect all participants to be polite, and I expect all participants to actually read, and actually respond to, previous posts in the thread. Anyone who just keeps saying the same thing without reading, understanding and responding to previous arguments may be warned and/or suspended.

[Edited by - hplus0603 on September 5, 2009 3:30:11 PM]

#24 Andrew F Marcus   Banned   -  Reputation: 100

Like
0Likes
Like

Posted 04 September 2009 - 06:33 PM

Quote:
Original post by Nypyren
Another thing to consider (at least in the real world) is that companies sometimes decide it's less trouble to retrofit their ANCIENT single-player codebases so that they are multiplayer capable. This is almost impossible to do if you use peer-to-peer.


All it takes is to forward the input and for other computers to use that data instead of some AI algorithm. It's the equivalent of making two player hot-seat game or split screen multiplayer.


Quote:
Original post by Jeonjr
Quote:
Original post by Andrew F Marcus
I'm sorry, but have you not in fact admitted server upload bandwidth is O(n^2) while peer upload/download bandwidth is O(n)? Do you realize how this means the same client bandwidth can allow for twice the number of players with P2P than with client-server?

...

Is it not the integrated bandwidth of O(n^2) in P2P still better than having just one client(server) use O(n^2) upload bandwidth? Does that not actually make P2P about two times more practical given the same bandwidth constraints?

I don't see how he is wrong here in the case that all clients have equal bandwidth and that if a client had to be a server.


P2P bandwidth cost per peer is O(n)
C/S bandwidth cost per client-host is O(n^2)

For example, if upload limit for all the clients was 20units, then P2P could support up to 20 players, while S/C approach could not support more than 4 players. Other mistake was him thinking how collective bandwidth usage is more with P2P than C/S, which is obviously wrong since server sends data to all about all and that makes it very wasteful and superfluous way to communicate information, making a pig out of one of the clients, hogging more bandwidth than all the peers together.

Hope that explains.


Quote:
Original post by Jeonjr
Quote:
Original post by Andrew F Marcus
Finally, having only two-player game, do you think it would be better if one player hosted the game for both, or would P2P type of direct link turn out as a better solution in this case?

seems to be about the same but writing p2p is harder to sync.


It is easy to write P2P programs and very much easier to sync them. Ask our friend "Stickman": "The multiplayer part is P2P, I've done my best on reducing latency and bandwidth, using various packing schemes and priorities. It works nicely with 30 people online, using only 5kBps upload."

http://www.gamedev.net/community/forums/topic.asp?topic_id=509402&whichpage=1�

#25 Andrew F Marcus   Banned   -  Reputation: 100

Like
0Likes
Like

Posted 04 September 2009 - 07:41 PM

Quote:
Original post by hplus0603
Quote:
I'm sorry, but have you not in fact admitted server upload bandwidth is O(n^2) while peer upload/download bandwidth is O(n)? Do you realize how this means the same client bandwidth can allow for twice the number of players with P2P than with client-server?


If there is no per-packet overhead, that statement would not be true, because squared and times-two are different functions.
If there is per-packet overhead, that statement would not be true, because packet overhead matters.


Packet overhead hardly makes any difference. Besides, it can always be argued P2P needs only to pass player input between peers. If my statement is wrong than it's because it's understatement, the difference is not "twice", but it rather grows exponentially with the number of players, in favor of P2P.


Quote:

Do you think that the people who wrote Counter-Strike: Source, or Quake III: Arena, or Unreal Tournament, are idiots? Do you think they do not carefully test a number of different approaches before they settle on what works best? Why do you think they are not using P2P topologies?


Yes, if there is no better explanation for not using P2P. Yes, they likely did not think, test, nor care to consider other approaches, most of them did not even write their engines, they copied what others were doing. Everyone is playing it safe, everyone is using one and the same code. Besides, many of them may falsely believe P2P has bandwidth issues. How do you explain it? It's not bandwidth, it's not latency, it's not security. What is it then?


Quote:

Anyway, the proof is simple: Just write a game that is P2P and works much better than current games based on Source, Unreal, Quake etc engines. There are lots of companies out there in the games engine and middleware business, and none of them end up using P2P solutions. If you can write a much better game, or simply license a much better solution, you'll make lots of money!


I wrote some even more incredible stuff, unfortunately no one cares and I am even giving it all away for free. Industry is very inert now days, there is so much money involved that it acts as an obstacle to inventiveness and progress, making all the games play and look alike.

Do you want to play Stickman? "30 people online, using only 5kBps upload"
http://www.gamedev.net/community/forums/topic.asp?topic_id=509402&whichpage=1


Quote:

I'll leave you with another question: We've all heard about MAG (Massive Actiongame), right? Do you think they use client/server, or peer-to-peer, for their 256-player matches? And why?


I don't know. They are being silly?

#26 Jeonjr   Members   -  Reputation: 122

Like
0Likes
Like

Posted 04 September 2009 - 07:58 PM

Quote:
Original post by hplus0603
If there is no per-packet overhead, that statement would not be true, because squared and times-two are different functions.


I do believe the server upload bandwidth is O(n^2) since the server needs to send (n-1) sized packets to n players during worst case scenario.

Quote:
Original post by hplus0603
Do you think that the people who wrote Counter-Strike: Source, or Quake III: Arena, or Unreal Tournament, are idiots? Do you think they do not carefully test a number of different approaches before they settle on what works best? Why do you think they are not using P2P topologies?


I think they don't use P2P because its not very secure, which leads to a lot of cheating/hacking.

edit:
Quote:
Original post by hplus0603
I'll leave you with another question: We've all heard about MAG (Massive Actiongame) [www.gamespot.com], right? Do you think they use client/server, or peer-to-peer, for their 256-player matches? And why?

P2P only works up to the lowest uploading speed of the client, which we know as increasing at the rate of O(n).
Where as Client Server requires O(1) upload for each client.
edit2: also the packet header is going to limit P2P even more as it requires each 256 players to send 255 packets each.
Client Server only needs 256 + 256 packets


sidenote: the link has an extra ' at the end (or is missing one at the start)

Quote:
Original post by Andrew F Marcus
It is easy to write P2P programs and very much easier to sync them. Ask our friend "Stickman": "The multiplayer part is P2P, I've done my best on reducing latency and bandwidth, using various packing schemes and priorities. It works nicely with 30 people online, using only 5kBps upload."

http://www.gamedev.net/community/forums/topic.asp?topic_id=509402&whichpage=1

I don't see how it's "easy" to write a P2P program.

[Edited by - Jeonjr on September 5, 2009 2:58:13 AM]

#27 Andrew F Marcus   Banned   -  Reputation: 100

Like
0Likes
Like

Posted 04 September 2009 - 09:44 PM

Quote:
Original post by Jeonjr
P2P only works up to the lowest uploading speed of the client, which we know as increasing at the rate of O(n).
Where as Client Server requires O(1) upload for each client.


Yes, but advantage only applies if some company is hosting a dedicated server, paying for all the bandwidth. Still, if the game is not super successful, servers will go offline rather quickly, leaving O(n^2) problem to you.


Quote:
Original post by Jeonjr
edit2: also the packet header is going to limit P2P even more as it requires each 256 players to send 255 packets each.
Client Server only needs 256 + 256 packets


Peer upload: 255 packets
Server upload: 256*256 = 65536 packets


Quote:
Original post by Jeonjr
I don't see how it's "easy" to write a P2P program.


I don't know what to tell you. You use exactly the same network code as in client-server approach, except that you run a server on each client, so to speak. Is there anything in particular you're worried about?

#28 Andrew F Marcus   Banned   -  Reputation: 100

Like
0Likes
Like

Posted 05 September 2009 - 12:25 AM

http://stickman.hu/
http://stickman.hu/page/?o=download&l=eng

Ok, this is absolutely fantastic! Stickman works wonderfully!!

There is quite a few people playing there right now, most of them seem to be half the way across the globe, in Hungary, so latency was probably about 400-500ms, but it played beautify nevertheless. There are clans, top players, high-scores, forums, all the stuff... this is really a quality game with many happy users to vouch for it.


It took me about 2min to play the game from the moment I clicked on download link. There is no need for installation or any kind of setup what so ever, you just download 10mb exe and run it. Simple as that.

Just like author says - "The portable version doesnt need to be installed, it just runs". Indeed, it just runs! Ha, great stuff. Click "connect" and there you are... running, jumping, driving vehicle, shooting Stickman half the way across the world. It's smooth, it's fun, it's great... bravo!




Stickman on P2P:
- "Interestingly, this is a P2P online game, and the server I talked about is a simple NAT introducer. It was a great challenge to reduce bandwidth to the minimum. But I think I got it right, because it only uses 5KBps upload with 50 players, so It could even work with Dialup!"

-"I use byte packing and some priority thing (like, I send packets more often to players, who are closer to me etc.), so there's less lag than you would think, since if you're shooting with someone, you send most of your packets to each other."

-"1000 players have played with it since i started to develop it. Not Massive, eh?"




I didn't think stick figures can get any better than Xiao-Xiao, but you did it. Stickman, you rule.

#29 Antheus   Members   -  Reputation: 2397

Like
0Likes
Like

Posted 05 September 2009 - 01:40 AM

Quote:
Original post by Andrew F Marcus
Peer upload: 255 packets
Server upload: 256*256 = 65536 packets


Maximum size of a packet is 1500 bytes due to MTU, minimum is 576. Depending on payload, server will be able to pack multiple payloads into same packet.

(1500-28)/255 = 5.7. This means, if payload is less than 6 bytes (quite possible), then server will send each client entire state of 255 players in single packet:
[UDP Header][C1][C2][C3]....[C254]


As such, server upload is 255 packets.

With 5 bytes of payload, the overhead of P2P is: 84%
With 5 bytes of payload, the overhead of server upload is: 2%

For every another 5 bytes of payload per client, server would need to send an extra packet.

This is where the difference comes from.

#30 Andrew F Marcus   Banned   -  Reputation: 100

Like
0Likes
Like

Posted 05 September 2009 - 03:03 AM

Quote:

Maximum size of a packet is 1500 bytes due to MTU, minimum is 576.


What do you mean - minimum?


Quote:

(1500-28)/255 = 5.7. This means, if payload is less than 6 bytes (quite possible), then server will send each client entire state of 255 players in single packet:

[UDP Header][C1][C2][C3]....[C254]

As such, server upload is 255 packets.


Ok, fair enough, quite a few bytes saved there. But packet is not a measure of size anymore and we need to plug in some real bytes, like so...

Peer upload cost: 254 *(28+5)bytes = 8,382 bytes
Server upload cost: 255 *1500bytes = 382,500 bytes



The difference remains huge.

#31 Antheus   Members   -  Reputation: 2397

Like
0Likes
Like

Posted 05 September 2009 - 03:22 AM

Quote:
What do you mean - minimum?


Packet fragmentation.

Quote:
Peer upload cost: 254 *(28+5)bytes = 8,382 bytes
Server upload cost: 255 *1500bytes = 382,500 bytes

The difference remains huge.


Yes, it does.

P2P upload: 8,386 bytes.
P2P download: 8,382 bytes.
S/C client upload: 33 bytes.
S/C client download: 1500 bytes.

Next, remember that this is *one single update*. You need 10-30 *per second*.

Now calculate the above numbers, taking into consideration payload merging, for WoW, or 3000 users per shard.

Then take into consideration that each user pays $15, and that each server is on backbone, with multiple gigabit connections.

If all you want to do is a little multiplayer game for your friends, then P2P will "work". If you plan on running a business, think again.

-------------
Edit, part II, The Heavy Cannons

So far, we have only been sending payload in raw form. But we have means of reducing it via compression.

Let's have a standard zlib compressor, which reduces the size of payload by 40%. UDP header cannot be compressed.

When sending 5 bytes, we reduce that to 3.

P2P, both directions, : 254 *(28+3)bytes = 7,874 bytes

What about server? Remember that we can compress *entire* payload, which in our case is all of 255 individual messages.

Server upload cost: 255 *(28+254*3) bytes = 201,450 bytes.


Now we apply this to real case. 10 updates per second.
P2P, both directions, 7,874 bytes * 10 * 8 = 629920 bits per second. While this is not horrible, 630kbits is more than upload of most users. It definitely doesn't work over dial-up.

S/C, client upload: 31 * 10 * 8 = 2480 bits per second.
S/C, client download: (28+254*3)*10*8 = 63200 bits per second.

In S/C model, user could just barely use V.92 USR dial-up modem, if only compression were slightly better (56kbits per second)

What about server:
UL: 255*(28+254*3)*10*8 = 16,116,000 bits per second.
DL: 255 * 2480 bits per second = 632,400 bits per second

Big numbers... But do they matter?

DL rate is same as DL rate of P2P model.
However, upload rate is much higher, but almost close enough to be hosted on a 10Mbit connection.

Now let's set what we would need in each case:
P2P: 255 users with 1Mbit upload, 1Mbit download connections

S/C: 254 users with just a little bit more than dial-up
S/C: one client with 20Mbit upload, 1Mbit download

Experience shows, that it's easier to find one player with very good connection and 254 users with really poor connections, than it is to find 255 users with decent connections.


And, despite the title - these aren't the biggest cannons. Then there is merging of state on server, removal of redundant messages, area of interest management, update prioritization, etc....


I'm curious, does everyone in this thread have 1Mbit upload connection? Mine is 8/2, but various bandwidth meter statistics say this ranks in top 10%, based on world-wide metrics. Then again, I can easily get 20/20 for just a bit more, or even 100/100 fiber for same price.

Is everyone in same position? Can you scale up your connection at next to no cost to symmetric fiber? Can your 255 friends too?

[Edited by - Antheus on September 5, 2009 9:22:06 AM]

#32 Ysaneya   Members   -  Reputation: 1247

Like
0Likes
Like

Posted 05 September 2009 - 03:47 AM

Quote:
Original post by Andrew F Marcus
Ok, fair enough, quite a few bytes saved there. But packet is not a measure of size anymore and we need to plug in some real bytes, like so...

Peer upload cost: 254 *(28+5)bytes = 8,382 bytes
Server upload cost: 255 *1500bytes = 382,500 bytes

The difference remains huge.


I think the comparison is meaningless. If you care about client performance, you should compare client in P2P versus client in C/S mode. Let's assume 50 clients, UDP header of 28 bytes and 16 bytes of data per client, cost per update/frame is:

P2P upload cost per client: 49 * (28 + 16) = 2,156 bytes
P2P download cost per client: 49 * (28 + 16) = 2,156 bytes
P2P global upload bandwidth usage: 50 * (49 * (28 + 16)) = 107,800 bytes
P2P global download bandwidth usage: 50 * (49 * (28 + 16)) = 107,800 bytes

CS upload cost per client: 1 * (28 + 16) = 44 bytes
CS download cost per client: 28 + (49 * 16) = 812 bytes
CS upload cost on server: 50 * (28 + (49 * 16)) = 40,600 bytes
CS download cost on server: 50 * (1 * (28 + 16)) = 2,200 bytes

Now, let's read that again: if you want to compare client in one mode versus client in another mode, CS is clearly a winner. If you want to compare global bandwidth usage, CS is *also* clearly a winner.

If you make a biased comparison, like comparing the P2P client to the CS server bandwidth usage, of course you'll arrive to a wrong conclusion, which is that P2P is better for the client... but you didn't compare with the client in CS mode. That's like comparing apples to oranges.

I also want to point out, since you seem to be very impressed by that Stickman game, that the optimizations the developer mentions (byte packing, lesser priorities for far away clients, etc.. ) are all equally applicable to CS and would save bandwidth in the same proportions.

Challenge: doing a comparison client P2P versus client CS, can you find a realistic case where P2P would clearly be the winner ?

Y.


#33 KulSeran   Members   -  Reputation: 2587

Like
0Likes
Like

Posted 05 September 2009 - 03:59 AM

Quote:

Ok, fair enough, quite a few bytes saved there. But packet is not a measure of size anymore and we need to plug in some real bytes, like so...

Unfortunately, this is totally incorrect. The underlying system uses packets, not raw "bytes". You have to consider information in packets.
1) The system sends a packet header that must contain data to route the payload. This is overhead that eats bandwidth.
2) Every high level packet will consist of one or more lower level packets. That fragmentation leads to overhead and lag.
3) They system will deliver a packet in whole, or not at all. So it doesnt matter how full the packet was, all the data and headers need to be resent. If you have a high overhead from your headers you'll waste a lot of bandwidth resending tiny amounts of data.

#34 Andrew F Marcus   Banned   -  Reputation: 100

Like
0Likes
Like

Posted 05 September 2009 - 07:06 AM

Quote:
Original post by Antheus
P2P, both directions: 7,874 bytes * 10 * 8 = 629920 bits per second.
C/S, server upload: 255*(28+254*3)*10*8 = 16,116,000 bits per second.


20Mb upload?! Fiber optics? Suppose you have it, but how would you feel about paying for 20mb per second? Beside that, I think you just proved how 255 players is no problem for P2P and average DSL/ADSL. By the way, how long does it take for server to calculate physics and collision for 255 clients?


Quote:
Original post by Ysaneya
P2P upload cost per client: 49 * (28 + 16) = 2,156 bytes
P2P download cost per client: 49 * (28 + 16) = 2,156 bytes
P2P global upload bandwidth usage: 50 * (49 * (28 + 16)) = 107,800 bytes
P2P global download bandwidth usage: 50 * (49 * (28 + 16)) = 107,800 bytes

CS upload cost per client: 1 * (28 + 16) = 44 bytes
CS download cost per client: 28 + (49 * 16) = 812 bytes
CS upload cost on server: 50 * (28 + (49 * 16)) = 40,600 bytes
CS download cost on server: 50 * (1 * (28 + 16)) = 2,200 bytes

Now, let's read that again: if you want to compare client in one mode versus client in another mode, CS is clearly a winner. If you want to compare global bandwidth usage, CS is *also* clearly a winner.


Challenge: doing a comparison client P2P versus client CS, can you find a realistic case where P2P would clearly be the winner ?


I'll take on challenge with this one - The goal is to be able to play the game, so the real winner is the number that can help you and your 49 friends do just that. Therefore, if you wanted to run the game on 30FPS it comes down to this:

P2P upload cost per client: 30 * 2,156 bytes = 64,680 bytes/sec
C/S upload cost on server: 30 * 40,600 bytes = 1,218,000 bytes/sec


Winner is everyone who is playing, and loser is the sucker who is hosting the game. With P2P everyone is a winner. By the way, how long does it take for server to calculate physics and collision for 50 clients?


Quote:

If you make a biased comparison, like comparing the P2P client to the CS server bandwidth usage, of course you'll arrive to a wrong conclusion, which is that P2P is better for the client... but you didn't compare with the client in CS mode. That's like comparing apples to oranges.


I don't know what to tell you. Can you make your point other than proving me wrong? I mean, none of your objections makes P2P any less practical. You are complaining about bandwidth, but please realize there is a point where certain number of players can only be supported with P2P, having the common bandwidth limits. To illustrate, if a maximum number of players on average Xbox 360 game with average ADSL is 16, that means P2P would be able to host 32 or more. So, don't forget, with P2P everyone is a winner.

[Edited by - Andrew F Marcus on September 5, 2009 1:06:11 PM]

#35 Andrew F Marcus   Banned   -  Reputation: 100

Like
0Likes
Like

Posted 05 September 2009 - 07:35 AM

Quote:
Original post by KulSeran
Quote:

Ok, fair enough, quite a few bytes saved there. But packet is not a measure of size anymore and we need to plug in some real bytes, like so...

Unfortunately, this is totally incorrect. The underlying system uses packets, not raw "bytes". You have to consider information in packets.
1) The system sends a packet header that must contain data to route the payload. This is overhead that eats bandwidth.
2) Every high level packet will consist of one or more lower level packets. That fragmentation leads to overhead and lag.
3) They system will deliver a packet in whole, or not at all. So it doesnt matter how full the packet was, all the data and headers need to be resent. If you have a high overhead from your headers you'll waste a lot of bandwidth resending tiny amounts of data.


Ok, but is that argument for or against P2P?

I agree overhead makes it less efficient for smaller packets, but that still does not make a difference. Say in 255 player game one peer has to resend (28+5)bytes which is very wasteful and inefficient, but when server needs to resend (28+1275)bytes it's still more, no matter how efficient it's still more, even when you compress, it's always more with a server.

#36 Gaffer   Members   -  Reputation: 422

Like
0Likes
Like

Posted 05 September 2009 - 07:48 AM

Quote:
abaraba says:
Peer upload: 255 packets
Server upload: 256*256 = 65536 packets


Incorrect.

Peer upload: 255 packets
Client upload: 1 packet
Integrated server upload: 255 packets
Dedicated server upload: 256 packets

Why exactly do you think the server must upload 65536 packets?

Why would anybody use client/server if this was true?

#37 Gaffer   Members   -  Reputation: 422

Like
0Likes
Like

Posted 05 September 2009 - 07:57 AM

Quote:
abaraba says
I don't know what to tell you. Can you make your point other than proving me wrong? I mean, none of your objections makes P2P any less practical. You are complaining about bandwidth, but please realize there is a point where certain number of players can only be supported with P2P, having the common bandwidth limits. To illustrate, if a maximum number of players on average Xbox 360 game with average ADSL is 16, that means P2P would be able to host 32 or more. So, don't forget, with P2P everyone is a winner.


To be fair mate you do make it pretty difficult to make a point without proving you wrong.

If you would like for people to stop proving you wrong, perhaps you should stop posting incorrect statements?



#38 Antheus   Members   -  Reputation: 2397

Like
0Likes
Like

Posted 05 September 2009 - 08:02 AM

Quote:
Original post by Gaffer

To be fair mate you do make it pretty difficult to make a point without proving you wrong.

If you would like for people to stop proving you wrong, perhaps you should stop posting incorrect statements?


I reject your reality, and substitute my own.

#39 Ysaneya   Members   -  Reputation: 1247

Like
0Likes
Like

Posted 05 September 2009 - 08:32 AM

Quote:
Original post by Andrew F Marcus
Quote:

Challenge: doing a comparison client P2P versus client CS, can you find a realistic case where P2P would clearly be the winner ?


I'll take on challenge with this one - The goal is to be able to play the game, so the real winner is the number that can help you and your 49 friends do just that. Therefore, if you wanted to run the game on 30FPS it comes down to this:

P2P upload cost per client: 30 * 2,156 bytes = 64,680 bytes/sec
C/S upload cost on server: 30 * 40,600 bytes = 1,218,000 bytes/sec

Winner is everyone who is playing, and loser is the sucker who is hosting the game. With P2P everyone is a winner.


Correct. There's a choice to make. In C/S (in my particular example), individual bandwidth per client is x5 times lower than for a P2P client. But you need a server with a capacity much higher than a single client. The good news is that companies, when speaking of a number of players over the two digits, normally provide such a server; therefore players don't have to worry about this kind of concern, and can play with x5 times as many players than in the P2P model.

Quote:
Original post by Andrew F Marcus
By the way, how long does it take for server to calculate physics and collision for 50 clients?


Roughly the same time it takes for a peer to calculate physics and collision for 50 clients.. ? The advantage being that a server can be authoritative while peers trusting each other opens the door to all sorts of hacks and cheats..

Quote:
Original post by Andrew F Marcus
To illustrate, if a maximum number of players on average Xbox 360 game with average ADSL is 16, that means P2P would be able to host 32 or more. So, don't forget, with P2P everyone is a winner.


Unless the server is hosted on a professional datacenter, in which case C/S would be able to host many times more than P2P and elegantly solve the latency/security issues that P2P has.

Y.


#40 hplus0603   Moderators   -  Reputation: 5729

Like
0Likes
Like

Posted 05 September 2009 - 08:56 AM

It is great that you're actually discussing the replies now. Let me reply to the replies, and I hope you can answer those as well.

Quote:
Packet overhead hardly makes any difference.


That has been shown wrong by numbers in a previous thread. The overhead of a single UDP packet is 28 bytes. If all you send is client commands, then the commands data packet is on the order of 4-8 bytes. Thus, packet overhead is on the order of 3.5-7x as important as actual data.

Quote:
Besides, it can always be argued P2P needs only to pass player input between peers.


Many client/server solutions only send player input between clients and servers, too. There's no savings from going P2P there.

Quote:
Quote:
Do you think that the people who wrote Counter-Strike: Source, or Quake III: Arena, or Unreal Tournament, are idiots? Do you think they do not carefully test a number of different approaches before they settle on what works best? Why do you think they are not using P2P topologies?


Yes, they likely did not think, test, nor care to consider other approaches, most of them did not even write their engines, they copied what others were doing.


That has not been my experience from actually talking to and in some cases working with those people. They each are very good engineers, carefully considering all the possible approaches, and choosing the approach that works best in practice. This can be easily verified by looking at the different network architectures of the engines: they each use a very different approach, so saying "they didn't write their own" or that "they were doing what everyone else was doing" is clearly false.
Because you can examine the implementation details for each of those cases, your statement of opinion about how those engines were engineered is thus provably false.

Quote:
Quote:
Anyway, the proof is simple: Just write a game that is P2P and works much better than current games based on Source, Unreal, Quake etc engines.


I wrote some even more incredible stuff, unfortunately no one cares and I am even giving it all away for free.


If it's very incredible, and you give it away for free, then clearly people will use it. If nobody is interested, then it's more likely that they do not share your opinion about how incredible it is.

Do you have a download link where people can make up their own minds about the incredibleness of your contribution?


Quote:
Quote:

I'll leave you with another question: We've all heard about MAG (Massive Actiongame), right? Do you think they use client/server, or peer-to-peer, for their 256-player matches? And why?


I don't know. They are being silly?


With dozens of millions on the line, and a studio of 150-200 people working for years on a game, do you think "being silly" is the reason why they're accomplishing something that nobody else has done before?

AFAICT, they're using client/server, and they're using user-input passing, and they're doing 256 simultaneous players. I suggest you try replicating that with P2P and see how far you get.







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