56 replies to this topic

[gbLinux]

hi,

ultimately, i wish to argue how peer-to-peer model is faster, much faster, than currently popular server-client model... and in fact, it has so many advantages over S/C that it is mindbogglingly unexplainable why in the world no online multiplayer game use it. why, why, why? but, if there are any games to use it after all, then please let me know about them. ok, here it goes...


THE TRUTH ABOUT SERVER MODEL
- central server collects all the input from all the clients, calculates movement/collision then sends to each client the new machine state, ie. new positions of each entity, velocities, orientation and such, which then each client renders, perhaps utilizing some extrapolation to fill in the gaps from, say network refresh rate of 20Hz to their screen refresh rate of 60 FPS.

to put it simply, games on the internet today run only about 10-20FPS of real server-computed data and clients input samples, regardless of how many FPS your client renders, but those extra frames are only "smooth-candy", and even worse, they may itself be the source of another set of visual artifacts since they can easily mismatch with server's next update.


it can be better, and it's rather simple actually,
but this is not news, p2p is nothing new as we all know, tho most will be surprised that no game actually use this as a main network model for the game, only for chat, patches and some side-stuff. so, one thing is clear, p2p works... but does it work better than server-client model? can it host the whole game? you be the judge!



1.) first let's consider round-trip traversal with the best case scenario for S/C model, where server is in the middle. -- shortest route should yield fastest path.

B        C


     s    30km

  20km

A        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




2. second, let's consider bandwidth...

packet overhead= 30 bytes
packet client input= 10 bytes
packet full entity state= 20 bytes
----------------------------------

C/S, client upload per frame: 40 bytes
C/S, client download per frame: 50 bytes * N_clients

P2P, peer upload per frame: 50 bytes * N_peers
P2P, peer download per frame: 50 bytes * 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



3.) third, updates are asynchronous, there is no FAST/SLOW here, no waiting - you only have FURTHER and CLOSER, and further is not SLOWER it is only more behind in the past, but the rate of update is NON INTERRUPTED, has CONSTANT streaming flow. theoretically working on FULL 60Hz and more, where frequency only depends on upload bandwidth, size of packets and number of peers. there is no lag, no glitches, no slowdowns, no waiting on server... only time dilation, depending only on DISTANCE.



CONCLUSION:
- P2P can not only allow for far better update frequency, but asynchronous, continuous updates will smooth many visual glitches automatically and the streaming nature of incoming data would even further make the whole experience more fluid.


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?

[TheNut]

Your own example actually demonstrates how a client-server architecture is much better.

1) Your reasoning here is slightly off. Yes, a round trip to and from the server would actually be about 42km. However, you're looking at this as a 1:1 relationship. What about the other 3 players that also get updated? The distance covered here is now only 21km. And the server sends out updates frequently with or without client input in most cases, so that's 21km for all players.

2) Bandwidth plays a very important role on client machines. Most ISPs loath when their subscribers use upstream bandwidth, especially on cable networks that are not designed for that behaviour (sad, but true). Residential networks have roughly a 1:20 to 1:10 upstream to downstream ratio. Dedicated game servers generally have a 1:1 ratio. So when a client only has to send a couple bytes out and receive larger packets from a single source, this is a good thing. You also have to consider congestion. Someone connected from a dense area like LA is likely to run into a lot of congestion issues compared to someone connected from Idaho.

There is also the matter of bandwidth caps now happily employed by most, if not all, ISPs today. Have you ever seen how much bandwidth a game like Battlefield takes up? Let me tell you because I analyzed it, among other games. In a 32 player game, a single Battlefield client consumes up to 32KB/s. That's a damn lot for a single user. 32Kb x 32 players = 1MB/s from the server, which is exactly what I recorded when hosting a 32 player game. I doubt any residential line supports that sort of bandwidth and even if it did, you'd hit your caps quite quickly.

3) Not true. P2P has every more reason to cause delay issues. As I mentioned in 2), ISPs limit residential upstream. Have you ever tried to host a game server on a cable connection? You would get at most 6 players, each with a latency of 100 ms. I know, my friends and I use to host games all the time. A P2P model means everyone is a client and a server, so each connection has the 6-player limit too.

Also, when someone connects from far away, say China, then all other players have to send a signal out that distance. That's an accumulated distance to China _and_ back causing all the more interruptions and delays whereas in a server model only the server has to deal with such a far away client. The dedicated server is also going to have state of the art networking, so it's likely the connection won't suffer as bad.


When it comes to large file transfers, I can see the benefit of P2P. That's why Blizzard employed that tactic and likely saves millions a month on bandwidth costs for patch updates. Supreme Commander is the only game I know of to implement P2P networking, but since most games are 1vs1 there's really no difference. There are pros and cons to both sides, but right now a client-server approach is the most sound.

[rouncer]

peer 2 peer is genius (save you a server bill) , but how do you stop the hackers?

[gbLinux]

TheNut said:

Your own example actually demonstrates how a client-server architecture is much better.

"better" for what? when clients have dial up connection? even then, it only limits the maximum number of peers per game. client/server model is simply byproduct of bandwidth constraints of the past.

Quote

1) Your reasoning here is slightly off. Yes, a round trip to and from the server would actually be about 42km. However, you're looking at this as a 1:1 relationship. What about the other 3 players that also get updated? The distance covered here is now only 21km. And the server sends out updates frequently with or without client input in most cases, so that's 21km for all players.

for the full frame to complete you have to send AND receive data, unless you are only spectating the game. ideally packets from all players should arrive in about the same time, but since this never happens in practice the server has terrible choice to make - to wait for sync or just continue. most of the games actually wait, so return trip does not only take more because of the plain larger distance, but you have to wait on "slowest connection", and then it takes time for server to process all that, and then the info has to come back to clients, and only when this frame is finally rendered, only then we can stop the watch and see how long did it take.

Quote

2) Bandwidth plays a very important role on client machines. Most ISPs loath when their subscribers use upstream bandwidth, especially on cable networks that are not designed for that behaviour (sad, but true). Residential networks have roughly a 1:20 to 1:10 upstream to downstream ratio. Dedicated game servers generally have a 1:1 ratio. So when a client only has to send a couple bytes out and receive larger packets from a single source, this is a good thing. You also have to consider congestion. Someone connected from a dense area like LA is likely to run into a lot of congestion issues compared to someone connected from Idaho.

why do you care about ISP? you pay for you bandwidth and you should be able to use it as you wish, just like you do. download/upload porn all they long if you wish, no one should care, but if they say something, spit in their face and change ISP.

if i can upload my photos and movies, if i can watch and listen streaming multimedia, watch youtube all day long, using my full upload/download bandwidth, then why do you think it would be a problem if the same amount of bytes is streamed for the purpose of the game? if people can exchange billions of illegal gygabites through p2p networks using they full up/dwn bandwidth, then the same should work for the game. isn't that so?

Quote

There is also the matter of bandwidth caps now happily employed by most, if not all, ISPs today. Have you ever seen how much bandwidth a game like Battlefield takes up? Let me tell you because I analyzed it, among other games. In a 32 player game, a single Battlefield client consumes up to 32KB/s. That's a damn lot for a single user. 32Kb x 32 players = 1MB/s from the server, which is exactly what I recorded when hosting a 32 player game. I doubt any residential line supports that sort of bandwidth and even if it did, you'd hit your caps quite quickly.

would you rather play a game for 5 hours on 20Hz, or 4hours on 60Hz? the bandwidth difference is not that big. for some people "better" is cheaper regardless of quality, for others "better" is better and they feel it is natural for it to cost more, that doesn't make it worse, only more expensive.

Quote

3) Not true. P2P has every more reason to cause delay issues. As I mentioned in 2), ISPs limit residential upstream. Have you ever tried to host a game server on a cable connection? You would get at most 6 players, each with a latency of 100 ms. I know, my friends and I use to host games all the time. A P2P model means everyone is a client and a server, so each connection has the 6-player limit too.

there are no delays in p2p caused by bandwidth, only if you setup the situation where clients would actually exceed their bandwidth. but even if all the clients had dial up, then they would merely be limited only with the number of peers that can be in one game at once, say 4... but if they have some average ADSL, then 16 or 32 players should be able to play without a problem, on 60Hz or even more. while server based approach can never achieve 60Hz with any of the clients, not even over LAN, maybe.


also, there is a neat thing you can do with p2p. just like servers can send updates to client only about other visible client or just of those that are nearby (in the game-world)... well, peers can do the similar thing much more elegantly, they can communicate on different frequencies depending on the distance. so if some peer is far away, in the game-world, you can send packets to that peer on much slower frequency, therefore drastically reduce bandwidth. you could send updates to peers that are out of visual range(in the game-world) on even 1 second intervals or slower, and increase the frequency dynamically as they close by to your field of view, therefore being able accommodate for all kind of connections on the fly, as a simple change in frequency could allow to switch from 'more players' to 'more frames' as desired.

Quote

Also, when someone connects from far away, say China, then all other players have to send a signal out that distance. That's an accumulated distance to China _and_ back causing all the more interruptions and delays whereas in a server model only the server has to deal with such a far away client. The dedicated server is also going to have state of the art networking, so it's likely the connection won't suffer as bad.

distance is distance, and having a server only makes it worse.

there is no FAST/SLOW here, no waiting - you only have FURTHER and CLOSER, and further is not SLOWER it is only more behind in the past, but the rate of update is NON INTERRUPTED, has CONSTANT streaming flow. theoretically working on FULL 60Hz and more, where frequency only depends on upload bandwidth, size of packets and number of peers. there is no lag, no glitches, no slowdowns, no waiting on server... only time dilation, depending only on DISTANCE.


imagine 8 people have radar devices that can read signal from similar device and display their location. all of them broadcast their location to all other and all the devices update location as the the signal arrives. now, this signal never stops and the latency here is directly proportional ONLY to distance.

again, latency does not mean SLOWER, only further back in the past. but even the stream of data from China to Italy, or wherever else, would have update rate as much as the bandwidth allows, easily 60Hz and more.

[alphadog]

gbLinux said:

i wish to argue how peer-to-peer model is faster, much faster, than currently popular server-client model... and in fact, it has so many advantages over S/C that it is mindbogglingly unexplainable why in the world no online multiplayer game use it. why, why, why?

First, your modeling is overly simplistic. In a real P2P network, there may be two or more nodes between you and the other node where there is a game state change that has to make it's way to your node. With a handful of nodes, P2P basically acts as a client/server network anyways. You have to model a game where you have 20, 200 or 2000 nodes, of varying bandwidth, of varying latency, across the world.

Latency is often the primary low-level issue. Yeah, eventually, that torrented DVD magically finds it's way to your grubby hands, but if the other player creates a pit in front of you that you walk over in your game because his state change message hasn't reached you yet, that makes the game suck.

Beyond that, there are many, many possible higher-level reasons that range widely. It's interesting that you think "faster" is all that matters to an MMO designer. What about security, integrity of data, internal consistency, synchronization, peer management, etc? What about tooling, libraries, staff training and existing capabilities? Do you think those are easy problems?

Technologically, distributed data is not an unsolvable problem, but is always much more complicated than client/server. (And, I hope I don't have to explain how much more expensive complex code costs versus the cost of buying a little bit more bandwidth...)

Basically, in a P2P system, each peer must have some (potentially large) proportion of the game world data local to the system, but it must be very quickly updated across all nodes. This creates all sorts of higher-level issues that have nothing to do with the lower level basics of latency and bandwidth usage you've explored.

Also, there's a more practical issue of "historical timing". You are complaining now when P2P and distributed computing is getting to be a prevalent way to tackle current technology issues (and still, as practitioners, our tools and "common understanding" is still young). However, mature MMOs played today were built a while back, designed even further back, when clients didn't have the bandwidth the have now, technologies were less mature, etc., and the decision you'd make now isn't the one you made 2,3 or 5 years ago.

"mindbogglingly unexplainable"? I would just say that it actually pretty simply explainable: it's naivete on your part.

Now, is it doable? Yes. Many emergent projects are trying out distributed concepts in MMO. (Ex: DHT databases for maintaining data across multiple nodes.)

[fireside]

Not being a social gamer I find this discussion interesting. I thought the reason for client/server was a matter of synchronization. The server collects all the data and keeps it in one place so everything is updated properly. This can be done with P2P then?

Hmm. I guess Alphadog answered it somewhat as being possible. I still don't quite understand it though. It sounds like everyone has to update everyone else's copy. That would complicate things almost exponentially with the number of players. Is someone actually doing that in the real world? I'm a scanner, I'll admit, but I didn't see any games mentioned.

[rouncer]

you spot out every 20th player is a mini server.

[martinsm]

Beware of the troll: http://www.gamedev.n...topic_id=545989

This is the same guy who trolled about timesteps: http://www.devmaster...ead.php?p=61304

[alphadog]

There are many ways to tackle the issue. Each comes with advantages and disadvantages. rouncer's idea is one way; basically instead of having fixed, centralized servers, you "float" authoritative servers over the pool of nodes, with fancier systems self-optimizing. A kind of pseudo-P2P. Or, you go fully peered, but usually latency is a bigger issue in those kinds of systems.

The biggest issue (ie. the most talked about) is security, trust and reputation. How do you dump basically all your game code and data on any peer joining in the peering? Well, it's pretty easy to hand-waive this with words like "encryption", or "reputation", and such. But, every word you use is another expense in building the system relative to a classic client/server system.

[alphadog]

gbLinux said:

why do you care about ISP?

A good game architect pays attention to the capabilities and limitations that will be available at time of the release of the project.

gbLinux said:

you pay for you bandwidth and you should be able to use it as you wish, just like you do.

This line, more than anything, makes me realize that the OP has no clue about the pressures of actually designing an MMO for the Real World.

[gbLinux]

alphadog said:

First, your modeling is overly simplistic. In a real P2P network, there may be two or more nodes between you and the other node where there is a game state change that has to make it's way to your node. With a handful of nodes, P2P basically acts as a client/server network anyways. You have to model a game where you have 20, 200 or 2000 nodes, of varying bandwidth, of varying latency, across the world.

latency issues can in worst case be handled just like server does it. there is really not much difference between p2p and c/s, as you said, it's just that computation is distributed, but all the problems and solutions still apply much the same. after that, p2p still gets to be faster for having shorter return path and whatever is the time penalty for packets to stop at server address and be dealt with until finally let go back to clients.

Quote

Latency is often the primary low-level issue. Yeah, eventually, that torrented DVD magically finds it's way to your grubby hands, but if the other player creates a pit in front of you that you walk over in your game because his state change message hasn't reached you yet, that makes the game suck.

all the peers are independent here, if the signal from one peer disconnects, then everything else should continue as usual, with just that client being frozen somewhere in the game-world. this is not very comparable with file sharing p2p networks, because those are about redundancy and data storage, this is just about signaling, so nodes are independent.

Quote

Beyond that, there are many, many possible higher-level reasons that range widely. It's interesting that you think "faster" is all that matters to an MMO designer. What about security, integrity of data, internal consistency, synchronization, peer management, etc? What about tooling, libraries, staff training and existing capabilities? Do you think those are easy problems?

Technologically, distributed data is not an unsolvable problem, but is always much more complicated than client/server. (And, I hope I don't have to explain how much more expensive complex code costs versus the cost of buying a little bit more bandwidth...)

i see now what you're talking about. this is not about persistent online worlds, not about massive multiplayer, just LAN/WAN networking option for some single player game for 8, 16, 32 or so players, like quake, starfleet command, x-wing and similar.

i'm not very concerned with security, i aim this solution to replace situations where there is no dedicated server, but some of the clients has to host the game, which makes it equally dodgy, or for the consoles where security is built-in, or is at least supposed to be... or for LAN games where security is no issue.

*** 32 clients, 20Hz, Client-Server Cost:
Client Upload: 800 bytes/sec = 0.006 mbps
Client Download: 13,420 bytes/sec = 0.10 mbps
Server Upload: 429,440 bytes/sec = 3.27 mbps
Server Download: 16,000 bytes/sec = 0.12 mbps

*** 32 peers, 20Hz, Peer-to-Peer Cost:
Client Upload: 31,000 bytes/sec = 0.24 mbps
Client Download: 31,000 bytes/sec = 0.24 mbps


while there is no way for average ADSL to support 32 clients game without dedicated server, p2p can easily manage even more players and/or higher update frequency. which makes me wonder - how all the games without dedicated server can manage to host any more than 8 players per game?

Quote

Basically, in a P2P system, each peer must have some (potentially large) proportion of the game world data local to the system, but it must be very quickly updated across all nodes. This creates all sorts of higher-level issues that have nothing to do with the lower level basics of latency and bandwidth usage you've explored.

yes, that's the idea, complete game would run on each client. imagine you are playing a single player quake on a special client device where each peer has radio antenna and it broadcast it's position in the game world via radio-waves. whenever some of those devices get turned on you would get a signal and your client would render that new player somewhere in the game-world. this is very similar how some mobile games use p2p over bluetooth, and the same thing should work over WWW just the same.

[alphadog]

gbLinux said:

there is really not much difference between p2p and c/s, as you said

There's not much difference with a small number of nodes. There are BIG differences that grow exponentially more difficult with P2P.

gbLinux said:

this is not about persistent online worlds, not about massive multiplayer, just LAN/WAN networking option for some single player game for 8, 16, 32 or so players, like quake, starfleet command, x-wing and similar.

What? Why are you wasting time with P2P for LAN games? You are adding complexity for a system that will get you nothing over the easier client/server model.

gbLinux said:

i'm not very concerned with security.

This means your game would be a guaranteed fail. What you are saying is that I can jack in and, with no security, basically control the peer network any way I want. You may not care, but your players will when they find out their fun can easily be ruined...

[gbLinux]

alphadog said:

There's not much difference with a small number of nodes. There are BIG differences that grow exponentially more difficult with P2P.

what is the big difference? what grows exponentially?

Quote

What? Why are you wasting time with P2P for LAN games? You are adding complexity for a system that will get you nothing over the easier client/server model.

it can get many more players in one game than server approach, wan/lan all the same advantages it has, where over LAN it could even use broadcasting and therefore even further speed up communication.

Quote

This means your game would be a guaranteed fail. What you are saying is that I can jack in and, with no security, basically control the peer network any way I want. You may not care, but your players will when they find out their fun can easily be ruined...

Xbox 360, ok? security can be managed just like with server model, you can have one of the peers be the judge, you can have voting system, you can have multiple judges, random... and if company was really concerned about it, they could run dedicated server in p2p as well, which could full-time do the policing and inspection of nodes.

[fireside]

Quote

what is the big difference? what grows exponentially?

I think it would be the number of messages received. In a client/server you would be sending one message and receiving one message per cycle. The server would be receiving all the messages from all the players and sending back one per player. Maybe in one sense it wouldn't matter, but there has to be some kind of verification or no one would be sure what was going on. It would also be taking care of persistence, etc. making sure if a player quits, he is remembered etc. Each client would have to take care of those tasks in a p2p wouldn't it? It seems like that would effectively make each client the equivalent of what a server is doing. So instead of the complex task given to a main server, that task is given to each and every client. I think they went to a client/server model for that reason. There might be a huge server system taking care of everything, but it's only one system and it can be given the best pipeline, large database, etc. P2P isn't being used for things that require constant update and I think there is an obvious reason for it. The potential for error would grow exponentially because every client is updating every other client. The fact that you see client/server on a lan party gives some idea of how fast it gets out of control, although maybe they're just doing it there for expandability. Doesn't mean you shouldn't experiment with it, though. I wouldn't. I can't believe people do the things they do with opening up their computers to other people like that.

[alphadog]

gbLinux said:

what is the big difference? what grows exponentially?

Basically, network and game state management "messages". The client still always says the same thing, eg. "move player 3 to x,y,z".

But, there's the addition of processing things like "Hi new node #3625!", "Hey, #1926, are you still there? Hello?", "Oops all the authoritative servers are gone, should I become master now?", "No. I am master.", "No. I am.", "Wait. Let's negotiate this based on reputation or voting.", "F'you. I'm master and here's the override code."

gbLinux said:

it can get many more players in one game than server approach

Your central server isn't limited to one physical box. It could be a virtual server actually backed by a server farm. Scaling this isn't intuitively obvious, but neither is a solid P2P architecture.

Here's where I am confused by your mixed-up argumentation. If we are talking about a LAN game, we're talking about tens of nodes at most. If we are talking of those number of nodes, then you would hardly be pressed to hit a limit in either C/S or P2P with a cheap laptop...

gbLinux said:

Xbox 360, ok?

Careful, just because you wrote the game for the XBox360 doesn't mean I, as a hypothetical hacker, can't use a totally different system type, jack into your network with a sniffer, reverse your protocols, and jam up your game solidly. Nothing creates a security hole like an unexperienced, ego-maniac developer!

gbLinux said:

security can be managed just like with server model, you can have one of the peers be the judge, you can have voting system, you can have multiple judges, random... and if company was really concerned about it, they could run dedicated server in p2p as well, which could full-time do the policing and inspection of nodes.

But, that's my point. Every technological feature you just said creates a larger codebase to write and maintain versus C/S, not to mention it adds to your support desk for "voting moderators", or even if those are volunteers, arbitrators that have to watch over community judges that "go rogue". Thanks for making the point for me.

At this point, I think you are theoretically convinced of the awesome superiority of P2P over client/server for LAN games and no amount of arguing will change your mind. I don't think there's any distinct superiority either way. You tradeoff a gain for a loss.

Therefore, I suggest you create a simple LAN or MMO game in both versions and see for yourself. Put your money where your mouth is, so to speak...

[gbLinux]

fireside said:

I think it would be the number of messages received. In a client/server you would be sending one message and receiving one message per cycle. The server would be receiving all the messages from all the players and sending back one per player. Maybe in one sense it wouldn't matter, but there has to be some kind of verification or no one would be sure what was going on. It would also be taking care of persistence, etc. making sure if a player quits, he is remembered etc. Each client would have to take care of those tasks in a p2p wouldn't it? It seems like that would effectively make each client the equivalent of what a server is doing.

number grows but not exponentially. the amount of communicated data is not much larger at all, it's only that p2p uses increased UPLOAD bandwidth, but with average ADSL this is not the problem.

yes, each client would be doing about the same task what server is doing for it, minus physics for all the peers - just for itself. but, don't make it look as a big deal, if your computer can run single player game where it needs to calculate AI and physics for all the computer controlled entities, p2p clients would require just about the same processing power. the difference is only where the position data for the entity is coming from, remotely or from AI algorithm locally, but the rest of the game should go on just as in single player game.

Quote

So instead of the complex task given to a main server, that task is given to each and every client. I think they went to a client/server model for that reason. There might be a huge server system taking care of everything, but it's only one system and it can be given the best pipeline, large database, etc. P2P isn't being used for things that require constant update and I think there is an obvious reason for it. The potential for error would grow exponentially because every client is updating every other client. The fact that you see client/server on a lan party gives some idea of how fast it gets out of control, although maybe they're just doing it there for expandability. Doesn't mean you shouldn't experiment with it, though. I wouldn't. I can't believe people do the things they do with opening up their computers to other people like that.

task is not complex at all, it's what game is supposed to be doing in single player mode without the problem, it's only complex if one computer has to do it for all the players.

peers can be synchronized just the same as in server/client approach.

opening ports means nothing, what you gonna do to security if the server on that port only understands "left", "right", "shoot", "jump".. ?

lots of ports on your computer are open as it is. do you have "remote assistance" enabled in your windows? have you ever seen what kind of crazy services run in the Windows background by default?

[fireside]

Quote

do you have "remote assistance" enabled in your windows? have you ever seen what kind of crazy services run in the Windows background by default?

I just de-activated it. It's probably paranoia on my part but I don't care for that kind of thing. I don't play online games. I don't mess with server systems so it's just academic on my part.

[alphadog]

gbLinux said:

opening ports means nothing, what you gonna do to security if the server on that port only understands "left", "right", "shoot", "jump".. ?

Ah! If I had a dollar for every naive developer that said this, then got their backsides handed to them on a platter...

[gbLinux]

alphadog said:

Ah! If I had a dollar for every naive developer that said this, then got their backsides handed to them on a platter...

should we believe you, since you said it with such authority, or would you care to actually say what are you thinking about?

Quote

But, that's my point. Every technological feature you just said creates a larger codebase to write and maintain versus C/S, not to mention it adds to your support desk for "voting moderators", or even if those are volunteers, arbitrators that have to watch over community judges that "go rogue". Thanks for making the point for me.

At this point, I think you are theoretically convinced of the awesome superiority of P2P over client/server for LAN games and no amount of arguing will change your mind. I don't think there's any distinct superiority either way. You tradeoff a gain for a loss.

Therefore, I suggest you create a simple LAN or MMO game in both versions and see for yourself. Put your money where your mouth is, so to speak...

i'm not sure what are you talking about. Flight Simulator has p2p networking which works just fine, as i managed to figure out by googling... Mario Kart DS, KartRider and bunch of mobile games via bluetooth or wi-fi. it's really hard to google any real performance information to figure out some numbers, but it seems players are quite happy.

we already have games that use it, we just need to find the people who can play them to tell us how it's going. unfortunately KartRider is offline, otherwise we could try it out right now. i suppose there could be all bunch of these little games on the internet in flash or java that actually use p2p for multiplayer, but it's hard to find them since no one really puts any 'game specs' on those online-game websites.

let's find a p2p online game and let's test it.

basically p2p is no different to "direct link", like two Game Boy can be connected or two PS2, or whatever... any additional nodes do not change the general situation since you can look at any pair of two peers independently as having "direct link" network connection. all the other peers can
disconnect and the game would still run. -- http://en.wikipedia....ki/Peer-to-peer "The distributed nature of P2P networks also increases robustness, and—in pure P2P systems—by enabling peers to find the data without relying on a centralized index server. In the latter case, there is no single point of failure in the system."


p.s.
if you and some friend of yours have iPhone, you can test it right away with some free games, so if you do - let us know.

[alphadog]

gbLinux said:

should we believe you, since you said it with such authority, or would you care to actually say what are you thinking about?

It's not really that difficult. For example, I get about 20 emails per day about new vulnerabilities discovered in applications from places like Secunia and other security outfits. Go do some research on sites like that and you'll get an endless list of failures in apps probably believed to be quite solid. I have had some of my apps hacked too...

gbLinux said:

i'm not sure what are you talking about. Flight Simulator has p2p networking which works just fine, as i managed to figure out by googling... Mario Kart DS, KartRider and bunch of mobile games via bluetooth or wi-fi.

Never said it was impossible. If you go back and actually read what I said, instead of look for an argument anywhere you can, you'll note that I never said don't do it. It's just not the "best thing since sliced bread" that you have been saying for a long time now in various dev forums.

BTW, if you want some real research, go read some papers from IEEE or ACM. You'll find groups like NICTA that are really looking at this kind of architecture in large settings.