Jump to content
  • Advertisement
Sign in to follow this  
iedoc

MMO Client == Server

This topic is 2332 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Networking has always kind of been my weak point, so i'm sorry if don't sound like i know exactly what i'm doing.

I'm sure if this has been done efficiently, it would be quite popular, but i don't really know where to look for any sources if there are any, or if this technique has a name or not, so i'm kinda wondering if there are any sources out there that might make this easier. If not, it's still a long way down the road before i begin working on the networking specific tasks for this project.

I'm working on an MMORPG right now. So what i'd like to do is to have a client connect to other clients instead of a central server. There will still be a central server which contains the database for the game, and do other tasks like updating the client software, connecting the client to the other clients and whatever.

I've put a little thought into this, like having the client connect to 3 other clients or so (in case one or two disconnect), choosing the clients depending on their ping (out of a group of random clients so they don't have to ping every connected player). When one or two of the 3 connections disconnect, the other one will send the data to the central database to be stored. This way the client will be receiving the same packet 3 times (one from each client it is connected to), instead of the 1 from a central server, but it also means that certain tasks could be done not on the client, such as collision detection. Of course this would open up a world of hacks, but they can always be minimized by checking the data that's been sent to the server with data from the other one or two clients. It would also allow the central server to spend more of it's time doing checks like this.

Any ideas on this? I'd prefer not to see reasons why this can't work (without an explanation, but more importantly, what would need to be done to make it work). Be productive and try to take it easy on me

Share this post


Link to post
Share on other sites
Advertisement
First off:

I'd prefer not to see reasons why this can't work[/quote]

Don't say things like that. If the only thing you ever want posted are the Pros to something, then you aren't going to get an unbiased picture of anything. Sticking your fingers in your ears and going LALALALALA doesn't work well :).

Past that, you've described a Peer to Peer MMO. There is one caveat that I notice in your description: You say that it would have no central server. But it does. You explicitly state that there is a central database. No matter what, you are communicating with said central database.

Now, you are going to run into a HUGE issue that is relatively insurmountable: you will find it very difficult if not impossible to prevent cheating. Modern MMOs use server-authoritive systems because the _server_ then decides what is valid. When you allow clients to do so, they can cheat and it is very difficult to verify. Are you going to let the other clients verify it? They can lie, too.

Past this, you are actually looking at MORE network traffic per client, but less to your central database (as it isn't authorative).

Also, how do you plan on propagating information from clients that are not directly connected? Is it going to be through the 'central database', or is there going to be some sort of web of connection? If the former, just implement a server-authorative system; you're halfway there without the benefits of it. If the latter, how are you verifying that all client nodes are connected to one another? Depending on the complexity of the connection tree, some clients may see relatively high amounts of latency.

Share this post


Link to post
Share on other sites
One thing to remember is that when an average user's computer is connected to the internet, it potentially has
1. a firewall and/or a restrictive proxy software running on his computer
2. a firewall and/or a restrictive proxy running on his home network box, local network, or company network
3. a firewall and/or a restrictive proxy running on his ISP's routers
4. a network address translation (NAT) layer on his home network box
5. a (second) NAT layer on his ISP's routers

All these prohibit you from spontaneously connecting direct peer-to-peer connections. The issue nr. 1 is sidesteppable by appropriate firewall exception configuration, the issues nr. 2 and 4 are sidesteppable by a knowledgeable user, but basic users don't understand how to do this. The issues nr. 3 and 5 might be sidesteppable by agreements with the ISP, potentially having money involved. Of course, you can't negotiate with ISPs for the customer's behalf, and you will generally need to be able to solve all of the items above.

The general techniques that are employed by peer-to-peer systems today to solve these are:
- NAT punchthrough. ([1], [2]) This is not possible with TCP for security reasons, but you will have to use UDP. NAT punchthrough will require a centralized arbiter to hand off connections.
- Masquerade into known ports, like TCP 80. Some firewalls allow inbound connections to these. Skype extensively utilizes these to penetrate network firewalls.
- Fallback to using centralized server architectures when neither of the above works. This might sound disappointing, but it is the only way to provide a robust system which guarantees 100% connectivity.

Skype and various Torrent architectures provide interesting case studies on how creating connections "from the internet" towards a single client can be handled.

Share this post


Link to post
Share on other sites

Networking has always kind of been my weak point, so i'm sorry if don't sound like i know exactly what i'm doing.

I'm sure if this has been done efficiently, it would be quite popular, but i don't really know where to look for any sources if there are any, or if this technique has a name or not, so i'm kinda wondering if there are any sources out there that might make this easier. If not, it's still a long way down the road before i begin working on the networking specific tasks for this project.

I'm working on an MMORPG right now.


This is a mistake. Any multiplayer project's design is deeply connected to its network behavior. I would recommend thinking about this sooner rather than later because otherwise you risk having to undo a lot of work to get your network implementation solid, and simultaneously risk breaking the game severely if you aren't painstakingly careful.


So what i'd like to do is to have a client connect to other clients instead of a central server. There will still be a central server which contains the database for the game, and do other tasks like updating the client software, connecting the client to the other clients and whatever.


What does this gain you?

What it loses is pretty substantial:

- Cheating will be trivial
- Players will desync with each other left and right
- You will create a vast amount of work for yourself
- Network traffic requirements will go up by a large factor
- Connectivity issues as clb outlined will make live very difficult

And I'm sure there are more negative consequences that would crop up as well.


I've put a little thought into this, like having the client connect to 3 other clients or so (in case one or two disconnect), choosing the clients depending on their ping (out of a group of random clients so they don't have to ping every connected player). When one or two of the 3 connections disconnect, the other one will send the data to the central database to be stored. This way the client will be receiving the same packet 3 times (one from each client it is connected to), instead of the 1 from a central server, but it also means that certain tasks could be done not on the client, such as collision detection.


I still don't understand what this buys you. Your game is now less reliable, more laggy, easier to exploit, and more frustrating to play for people behind firewalls/routers. There seems to be no positive side to this at all.

Consider this scenario: players 1, 2, and 3 are connected peer-to-peer. Player 4 enters the world and starts playing in the same area as 1, 2, and 3, but player 4 is connected to players 5, 6, and 7 instead of 1, 2, and 3. How do 1, 2, 3 see player 4? Either they can't (in which case your "MMO" is really not going to be very enjoyable) or you have to relay through potentially dozens of hops before you can get updates from 4 to players 1, 2, 3. Latency is going to shoot through the roof and desynchronization will be rampant.

Of course this would open up a world of hacks, but they can always be minimized by checking the data that's been sent to the server with data from the other one or two clients. It would also allow the central server to spend more of it's time doing checks like this.


So all I need is two (or three) clients to tell the same lies, and I've broken your protection.

I think you're misunderstanding the work load on the server as well. Instead of just simulating the world once and verifying that all clients are in line, you have to simulate every client because they will drift apart to some extent because of your latency-multiplying peer-to-peer design. So instead of one world sim for everyone, you now need to simulate one world per client on your server. There is no way on earth that is going to be a net gain ;-)


Any ideas on this? I'd prefer not to see reasons why this can't work (without an explanation, but more importantly, what would need to be done to make it work). Be productive and try to take it easy on me


There is a reason nobody does this - because it can't be made to "work" in the sense of actually doing what you want, being robust, being responsive, and not having huge negatives. It's not because of some secret cult that loves servers and assassinates people who try to think for themselves and defy the server-centric gods ;-)

Share this post


Link to post
Share on other sites
haha! thanks for the responses, they were very good points, although the outcome of this idea isn't looking too bright anymore

apoch, i know your right, i need to be thinking about the networking now because it's very important to the structure of the game, that's sort of why i'm asking about this now. i'm not ready to implement any server client stuff yet, but i'm making sure to design the game so that data can easily be sent, received, and processed, just not sure how i'm going to be sending or receiving them yet.

i wrote this when i was a little tired, so when i said "I'd prefer not to see reasons why this can't work", i didn't mean i don't want to see reasons why this can't work, even though that's exactly what i said, i just meant that if this WAS to work, what would need to be done, of course, the cons of it will need to be known so we can fix them to make it work. i didn't mean to sound rude, sorry. I'm thinking this probably isn't going to work after all, but after thinking about it some more, i think i can describe it a little better.

First, connecting to 3 other clients won't really work that well anyway, since that means every client HAS to have at least 3 people connecting to them as if they were the "server" and connecting to 3 other clients as if they were the server. that's 7 connections at least (1 for the central server). I think saying server is also the wrong thing to say. Of course, there will be a central server so people can see each other and whatever.

so anyway, one more go at this, even though i see it's probably a lost cause. What if every client connected to another client, so that other client can do things like collision detection on their computer, then send the result back. like, if your playing the game, then all the rendering and drawing are processed and done on your computer, but when you give input, that input is sent to the client you are connected to, where it is processed. So all the rendering is done on your own machine, but the game processing is done on someone else's machine. like cloud computing right?

I know that would open a new door to cheating, but if you don't get to choose the client you are connecting to, and the server can verify you are connected to the client it gave you, then minimizing hacks would be the same as a regular client/server connection, except that now you wouldn't be able to cheat for your own character unless you got lucky and you have two machines and somehow you randomly got connected to your second machine. the less people playing the game, the more likely chance that this could happen, but you would still need to figure out how to hack the game itself, but that's a different topic i think.

really only the input is sent to the other client, who is connected to the central server on your behalf, then the result of that input is returned to you. frame rate would depend on the connection to that other client. I really think this would minimize cheating if done right. you are still connected to the central server though, for the person who is connected to you for you to do the processing for them, and for any other reason you need to be connected to the server that doesn't have to do with your game character or whatever, like maybe if you get disconnected from the other client, the server can send you a new connection.

I know this probably won't work, and the lag might be terrible, but any more ideas? Edited by iedoc

Share this post


Link to post
Share on other sites
if all the game processing is done off the clients machine, doesn't that make it nearly impossible for him to cheat? originally i had the idea that if players could use the network of other players as the server, then the main game server wouldn't have to do anything really but hold a database, update client's software, and connect them to other players, and act as the little glue that keeps the players all together. I also know it's not too difficult to make a hack for a game so you are able to walk through walls fake collisions or bypass a collision check, such as when players attack each other

dos attacks could be a huge problem, but it wouldn't really gain the player anything by doing it, since he would freeze on a frame while he's waiting for a response from the client he's attacking

i guess another big problem is that since everyone is connected to one other client, then if there's an odd number of players, someone will have to have at least 2 people connected to them, and do the processing for both. not to mention when a client disconnects that had someone connected to him, then that other person will have to wait for a new connection with someone else, and for that new connection to load all the geometry that needs to be checked for collision. maybe it's really not a good idea... haha

maybe people could get extra credit for the time they leave their client application opened, so even if they are not playing the game, another player could use their system resources to do all the processing. Edited by iedoc

Share this post


Link to post
Share on other sites
Cheating can only be increased by giving any client authority. The client might not be able to choose to run at twice speed, but they could make their peer run at half speed. If you peer clients by location, then cheating "clusters" like a clan could easily end up simulating for one another, with obvious consequences.

By giving any authority to the client, even if it doesn't extend to the player using the client, introduces scope for cheating. What about teleporting the peer close to the client, and then abusing the simulation to defeat that player on that peer and steal their loot?

I don't know how this concept would extend to situations where large numbers of players gather nearby. It would be extremely complicated to get a consistent simulation over internet latency between the systems. Which player dealt the killing blow to the dragon? Jimmy's peer claims his axe removed the last few HP, but Jane's peer is adamant that her Lightning Bolt of Hurtiness did the final damage.

I think you need to create a list of pros and cons for this idea. If you are honest, you'll find the pros are fewer than the cons, and the cons have much larger implications.

Share this post


Link to post
Share on other sites
I know i probably shouldn't keep this going now, but stopping a person from teleporting his peer close to him would be the same as stopping him from teleporting himself if all the processing for his character was done on his own machine.

it's true that giving the clients any authority is grounds for hacking, so my original idea looks settled, but i still think if all the processing that would usually need to be done on someones own machine is done on someone else's machine, it would minimize cheating even more. the clan thing is a good point, but even then, if they were able to cheat for each other, they would be able to cheat anyway if the processing wasn't done on their own machine.

i've decided not to put any effort into doing something like this, but if you have any more good points, i'm still interested

Share this post


Link to post
Share on other sites
You're still mistaken about the architecture actually decreasing cheat potential.

It makes it a little more interesting, but frankly, all that's going to do is draw better attackers to the challenge.



Consider this scenario:

- Player A is connected and playing, with his simulation running on Player B's machine
- Player B decides he hates Player A
- Player B turns on a tool that starts reporting bogus information about the simulation to Player A
- For instance, Player A might now be told he's walking through lava and lose 5 HP/sec for forever

You've made it a little more awkward to cheat directly in your own favor, but even that isn't all that big of a deal. What you're actually doing is making a game that is prime spawning grounds for griefers.

It's still totally possible to cheat in your own favor once you know how the system works. For instance, all you have to do is tell the right lies to the right clients. Consider a PvP mode of your game:

- Player A is innocent and hosted by Player B
- Player B is malicious and hosted by Player C

Since Player B controls A's simulation, he simply tells C that he's always 2 inches behind A, and constantly firing off laser beams into the back of A's skull. C has no way to verify this under your proposed scheme, so C believes it. Somehow (via some magical mechanism you've declined to elaborate on) A then finds out that he's dead, because C's simulation said so.

Like I said, you're really not actually improving the situation. You're requiring a little more creativity from your attackers, but the first lesson of security is as soon as it's a challenge more people will try to attack it - and there will be some very smart people in that group.


Now, suppose your game has an economic side. With your peer-to-peer topology, I guarantee I could permanently devastate your game economy in a matter of hours at the most, maybe less if your game implementation is sloppy enough. All I have to do is lie to people to try to sell items while I'm their host, and refuse to let people buy items at the same time.

You should always assume that the attacker has 100% of your source code and can forge any network traffic he pleases. It's basically true whether you like it or not. And as soon as you open up any compromised computer to being an authority on the simulation, that compromised machine can do whatever it damn well pleases with your simulation's contents.


Think of malicious attacks like herpes. You don't defend against herpes by "spreading the love" to as many people as possible. That just gives you more infected people to continue propagating the disease.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!