 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| PROOF: P2P is faster than C/S based model for online multiplayer games |
|
 |
gbLinux Banned Member since: 8/27/2009 |
|||
 Posted - 8/29/2009 8:41:44 PM |
||||
Quote: hplus0603, troll? what kind of insult is that? what are you talking about and why in the world would you close public discussion without caring if other people wanted to talk about it? what is this? p2p beats server based model and i have proven it... even if not this is " Multiplayer and Network Programming" forum so this discussion very much belongs here, sheesh!! let other people talk about it, you grinch. packet overhead= 30byte packet client input= 10byte packet full entity state= 20byte ---------------------------------- C/S, client upload per frame: 40 C/S, client download per frame: 50 * N_clients P2P, peer upload per frame: 50 * N_peers P2P, peer download per frame: 50 * N_peers *** 16 players, per one client, per second, 60Hz C/S: upload= 40*60 = 2400 bytes/s C/S: download= 50*16*60 = 48000 bytes/s P2P: upload= 50*16*60 = 48000 bytes/s P2P: download= 50*16*60 = 48000 bytes/s *** 32 players, per one client, per second, 60Hz C/S: upload= 40*60 = 2400 bytes/s C/S: download= 50*32*60 = 96000 bytes/s P2P: upload= 50*32*60 = 96000 bytes/s P2P: download= 50*32*60 = 96000 bytes/s of course, with the huge difference that P2P could actually work on real, uninterrupted 60Hz, while server will lose more time as the number of clients increases, and can hardly achieve 60Hz communication update rate with any of the clients, maybe not even over LAN.. but how would i know? 1.) does p2p have shorter traversal path than server-based model? 2.) would parallel computing even further speed up latency by getting rid of serial computation server does? 3.) can p2p run on much faster frequency (60HZ and more) due to the nature of uninterrupted, streamed, asynchronous updates? |
||||
|
||||
|
KulSeran Member since: 12/9/2003 |
|||
|
Posted - 8/29/2009 9:44:27 PM |
||||
| 1) No. Likely longer. Peers are on the ends of the routing tree. Servers are often very close to the backbones. The difference may be small for GEOGRAPHICALLY CLOSE peers. But as soon as you increase distance physically, you drastically increase the number of hops a packet has to make between peers. 2) Nope. Servers do parallel computation on hardware, with large amounts of very fast RAM, and 16+ processor cores. Take a look at folding at home. IBM blade centers will be equivelent to ~2 or ~4 PS3's worth of computing power. That amounts to ~4x the compute power with ~1/8th the number of PS3s as it would take x86 home computers. Servers are easily going to run 24x better than the home PCs. But you also have to consider that your home PC is going to be bogged down with more than just physics. Most of the client's CPU time is going to be spent: *processing packets(unless you wasted 400$ on a network card that offloads that. Noting that servers WILL have that type of hardware) *sending data to the GPU *task switching to other resident programs on the clients computer (voip, IM, audio player, web browser, etc) The server doesn't have to deal with any of that. It will have hardware to help with the packet processing, there is NO GPU, there are only minimal other resident programs running. That single server is therefore going to be able to out preform "The Cloud" of hundreds of clients. 3) The thing P2P is good for is not bogging down a server that has limited bandwidth and high data size. That is why BitTorrent and the like took off. Even games like WorldOfWarcraft use that type of P2P. It makes it easy to distribute a 100Mb patch to millions because it only sends out data to geographically separated areas, and the peers in any geographically close location will end up quickly sharing the patch. But this type of communication EASILY overloads even ISP backbones. The bandwidth usage is huge compared to ClientServer. Combine that with congestion issues that arise from high usage and you are in trouble. Consider copying a file from one HDD to another HDD. Now, start a second file copy. It will now take more than twice as long to copy BOTH files than if you had done one file THEN the other. Routers have the same problems, you overload them, they slow down and start dropping packets. Normally that overload point is very high, but it can still be reached. Also, after reading your other line of posts, I suggest you take a moment to read and research and respond. Your attitude IS quite antagonistic(read trollish), and you seem to be failing to grasp concepts only to repeat the same exact questions even though they have been thoroughly answered. hplus0603 was quite justified in closing the last thread. If you can keep this one more civilized, you may be able to get more out of it. [Edited by - KulSeran on August 29, 2009 9:44:35 PM] -------- My Projects |
||||
|
||||
|
Sirisian Member since: 10/5/2005 From: kalamazoo, MI, United States |
|||
|
Posted - 8/29/2009 10:21:23 PM |
||||
Quote: Wait you do know how to program right? Or are you looking for a library that does P2P? You can program a P2P system just using sockets like you normally would. This thread will probably be closed. If you want you can discuss this on #gamedev on irc.afternet.org. It's pretty clear you've never done network programming. That's alright but try not to take criticism so hard. You're a little defensive. Remembering that I want to point out all of your math and numbers are wrong. |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
