Sign in to follow this  

Weird MMO network structure "dream"

This topic is 4827 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

I'm usually assauted by dreams (you could call it idea trips, but they actually happen when I'm asleep) of programming structures -- and I don' have much credibility 'cause I'm no programmer. So, I'd like to leave this open for discussion about technical issues, viability and stuff. The point here is a MMO's game struc kinda inspired in eMule / Torrent. The game's a kind of P2P, where the clients proccess stuff and passes the results to the server -- quite basic, and totally unreliable in the cheating matter. The diferential is, the client doesn' runs his own character -- it runs two other random people's characters. Hard to imagine? Lemme explain: When you login, you pass thru the Master Server, who does all the autenthication stuff. When the player is validated, the server aggigns him to two random already-connected clients (known as hosts). When the player does an action, (like, walk) it sends a signal to both hosts, who does the calculations and stuff (like, check if he can be in the next square, and confirm if he can). Both send the processed stuff (confirmation) to the Master Server, who compares results; if it's equal (in this case, both machines says he can and gives the same pathway), the action is valid and passed ahead to everyone who could use it, including the original client. Basically, each machine hosts two clients, and each client is processed by two machines. Cheating is complicated, 'cause the Master Server can be intolerant with different results (ie: kick), and defeats the purpose of cheating. (you'll be cheating other people's characters, not yours! Unless if you're a griefer.) And ultimately, gets rid of server load. I hope anyone else got the idea. Thoughts?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I think this should be in Multiplayer and Network Programming.

Share this post


Link to post
Share on other sites
That actually sounds good!

####BUT, there are a few problems.####

********Problem********
"(you'll be cheating other people's characters, not yours! Unless if you're a griefer.)"
***********************
----solved----
Even in this case one could just randomize the players, one player would process some players pakages, but next would be a completly diferent one.
----solved----

********Problem********
If the server kicks someone for diferent results, he would have kick at least two of them. since he can not know wich one is providing the wrong results, he just knows they are diferent.
***********************
----solved----
The server would just have to keep a counter, once a player supplies two diferent results, he's kicked. This way we have an indication that he is the one cheating. Since 'a' and 'b' gave diferent results and 'a' and 'c' gave diferent results aswell, there is a good chance 'a' is doing it. Unless 'c' and 'b' where doing it, but that's a very small chance, and they eventually get caught.
----solved----

********Problem********
Then there is the lag, the processing power needed to host such a game would be considerably lower wich is good, but the bandwidth requirements would increase, and these days i think the bandwith is more of a bottleneck then the processing power on MMORPG's.
***********************

********Problem********
And there is the lag, now we have to wait for a apakage when it travels from us to the server and back, with this scheme, we'de have to wait from us to the server, then from the server to the slowest of the two processing players, then from the slowest of the processing players to the server, and then from the server back to us.
***********************

[Edited by - White Rabbit on September 14, 2004 11:25:03 PM]

Share this post


Link to post
Share on other sites
Hello,

WOWSERS, you actualy have a very similar idea to what i am currently finalizing (as in the library is almost complete ;)). While mine isnt COMPLETELY decenralized (because of the potential headaches of ppl with different clients (ie: diff version or well-hacked) almost everything is decentralized.

Basicaly the network consists of two different potential "servers". The client & the banking server. The banking server acts just as its name implies, like a bank. There are 3 things the banking server does, 1 is handle the CVS-esque content distribution (im not getting into this now), the second is player accounts, the third is every tangable item (that can be put into inventory)

ACCOUNTS:

When the user creates a user name, they are (underneath the covers) assigned a unique 32bit hash identifying there username. Every time they log in they are assigned another 32bit hash (applied to the end of there ID code, specifying there access bit). clients outside of oneself know the player by there first 32bits, but the individual knows himself by the full 64, allowing one to control levels of access to the account.

Attached to the account is all of the accounts assets. This includes stats and items. Each stat/item also has a 64 bit hash identifying it. The first 32 bits are identifyable to anyone, the last 32 bits are only known by the actual account owner (a "password" if you will). The last 32 bits are changed semi-reguraly, at least once every transfer/login.

Now, how this works is like a standard banking system. To intiate a transfer (be it gold/items from a battle, from an actual transfer, etc.) is that the person who is losing the item tells the server that he is transfering an item and gets a particular 32bit transfer number for it. Then he tells the client the 32bit identifier and 32bit transfer number. Now the client recieving the item takes the item and transfer number, as well as the first 32 bits of the players account, and initiats a transfer. The original client is asked permission, and in response sends the transfer code with the full 64bit identifier to the server. In order to make sure the tranfer is "correct" and isnt cheated in case of purchasing something or other, the client that polls second can use the same transfer number and do the same thing. When the client is asked to send the 64bit identifier, it only has to do it if it is proper or "fair" (the client knows what its getting into). This is all done beneight the scenes by the way.

As for simply knowing whats in the inventory then? They simply do a 32bit check on the banking system account and they get the general inventory (some items may require the owners approval before awknowledgement is given out though).

Mind you, these accounts do not necessaraly hold PLAYERS, but also WORLDS and such. A player owned world populates itself with items from the banking server, and these can and will be checked by the banking server.

AS FOR MAPS:

standard Maps are transfered via CVS policys from the banking server. The server will send it to people acting as hubs, who do version checks reguraly. This keeps maps standardized. The server does not need to be polled for map locations because it is managed by the hub that owns the map. Player lists (the first 32bit hash per player) availiable on the map is on the banking server, and simply making a map pole (another int) will get you the list. (this is actualy hashed up in such a way that only 1 in every 100-500clients actualy would have to call in for such a list, and they should (what i am working on now) automaticaly be selected based on their line speed.

FIGHTING:

I called it the veto system :). Basicaly, in addition to what they are currently doing, everyone also is running either a battle or commune. Basicaly they act as a mediator between 2 people. It may seem worrysome that that person may be using a hacked client that is capable of rigging the fight, but its more complicated then that. For starters, your HUB is responsable for deciding which battle server (randon), and secondly, both clients are given a battle identifier allowing them to check certain things with the banking server, making cheating pretty much worthless. The random seed which is used is polled from the banking server.

SOMETHING ELSE I SHOULD MENTION

when i mentioned polling the banking server, you actualy arnt ALWAYS polling them. Most of the time this information is in the catch of your "HUB". IE: the hub calls for shit before a battle, the battle server calls for shit, and you call for shit from the HUB.

In preliminary tests (ASCII of course) I was able to safely manage over 5,000 people off a single 512k line. Not totaly distributed, but close too....

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Things to keep in mind:

Minimize how many times you transfer data

User(command) -> 'Host' -> Server -> User(result)

is a longer delay than

User(command) -> Server -> User(result)

(besides potential impact of waiting for 2 'Hosts' data to
converge/synchronize at the 'Server' for validation.



Need for a dynamic reassignment of processing on failoure
4 machines which potentially can fail (User+2*Host+Server)
vs
2 machines potential failure (User+Server)

ALSO not all 'Hosts' have the same capacity (excess CPU resources beyond what is needed for 'client' operation)


Data required for Hosts(2) to calculate action results
must be replicated on those 2 hosts -- stream of situational
updates must be maintained in a timely fashion to render valid
action results (those 2 hosts must calc using same data).



The system I'm working on (for way too long) relies on AI CPU
nodes closely coupled to the server(master data) -- 100Mb and 1000Mb LAN to quickly blast data updates (low latency vs having node on other side of internet connection).

Unfortunately even broadband (currently) is insufficient for
delivery of the masses of asset data required (dynamic maps & content and user supplied assets that change on a daily basis).
It will need LAN like thruput for the clients.....

Share this post


Link to post
Share on other sites
>Data required for Hosts(2) to calculate action results
>must be replicated on those 2 hosts -- stream of situational
>updates must be maintained in a timely fashion to render valid
>action results (those 2 hosts must calc using same data).

That's taken care of, The hosts USE the same data -- the client sends the same request, in the same place, etc. I thought that was implied.

And yes, I realize the "hosts with different speeds" problem, but I don' think that will be a real issue. As far as I researched, what makes games really heavy is rendering the output, (graphs, sound, rumble pack activation) not the internal processes, and the hosts won't be doing that three times.


WhiteRabbit:
>********Problem********
>Then there is the lag,

Lag? Er.... I guess I ddin' thought of that... nor the server-side bottleneck bandwidht (he sends data to 50 players but recieves from 100, technically) ...well...

As far as I know, in any given connection, willing or not, you have more download than upload band. If that's true, I'd be only using unused download band. I think.

Let's wait some more, uh, five years? Bandwidht will get cheaper there, I guess ^^;;


Paul Ceasar: I'm glad to know there's someone in the world trying unorthodox methods of making stuff work. Well, the max I can do is to bid you success, unfortunately ^^;;

Share this post


Link to post
Share on other sites
In a typical client-server setup, you have x connections for x players. This is flimsy enough as it is.

In the scenario you're describing, there are 5x connections. Each player connects to the server, to the two players he is managing, and to the two players managing him.

Each player is relying on two other machines not to fail (not counting the server), and on 5 connections not to fail. You'd be lucky if this setup lasted for more than 5 or 6 minutes at a time.

And of course, there's the required bandwidth. You have to download from the server, and two users giving commands, and you have to upload to two users you give commands too, as well as two users' worth of data to the server.

It would certainly curb cheating, but given the current state of network technology, it would also curb playing.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
1. You've been pre-empted by Crosbie Fitch and his "Systeme Segundo" project. But...he's been looking for volunteers for the last 5+ years, so you could probably go chat to him and he'd happily talk to you. Personally, I think he's a little insane and I've got quite bored of his continual blind faith in these P2P MMOGs, because he generally doesn't believe any of the real problems that the experts keep pointing out to him. However, some people consider him a visionary, and you may even decide he's a genius. Certainly worth checking him out - he's put considerable time and effort into exploring these ideas.

2. The idea mooted here is the kind of thing I'd encourage a phd student to work on if I were their professor: it's a great research project. But..as a viable technology? It sucks. I speak from having participated in many very long conversations with Fitch and others - basically, this kind of thing WILL NOT WORK in general today; reasonable extrapolations of consumer internet access improvements suggest it will start to be viable in around 10 years time to mass market in USA and europe. However, that's optimistic if anything. There are many many problems. Some are very subtle, others are in your face.

3. Latency is one of the biggest problems of all; keep thinking about it until you've got really scared, then you'll probably have uncovered the can of worms that's there. I'm summarising massively here, but it is *DIFFICULT* for expensive dedicated servers to keep latency down in MMOGs; it's much harder to do so in commodity distributed systems over even lower quality links!

4. All the stuff mentioned above about reducing cheating is almost totally ineffective. Current knowledge on cheating shows that it's damn easy to get 500 people to collude with you to cheat. 90% of P2P MMOG systems and architectures that are presented to me (and I see a lot in my day job) make assumptions like "it would be hard to get 5 people to collude, and almost impossible to get 50. This system is mostly effective as long as you can't get more than 30, and universally effective if you can't get 50". Mostly, I'm not very kind to people who can't be boethred to research the background of their topic and find out what large scales people regularly collude on in online games and MMOG's...If your trust system requies collusion of 75% of the userbase in order to subvert then you are ready to start considering it possibly viable.

5. bear in mind that in many cheats it is sufficent to subvert *any* battle - it is NOT necessary to guarantee to subvert your own. This is a basic mistake made by devs not familiar with security engineering...The DoS attack on a game server can be very effective at allowing people to cheat, if the cheater is devious enough, and yet it's damn easy to pull off. Most devs are blissfully unaware of this, until they actually get close to completion on a real MMOG. :(.

redmilamber

Share this post


Link to post
Share on other sites
On the security front, the other downside is...

Hey, I got the IP's of people that play this game. Now I have a direct target to aim at if I want to hack/"walk through the open doors"/drop a trojan on them to get their login info/etc.

Share this post


Link to post
Share on other sites
Well hmmm... if I decide to start changing all of my out going packets, wouldn't I be DoSing 2 players? (edit: guess I didnt read the previous posts :P) Because my data would never match up with the other clients who I am calculating for. What about if all the people controlling my character log off? Personally I dont like the idea of any other computer than the master server controlling authentication, because for games, that leads to doom :(. If this game is really worth cheating in, people will find a way to do it. Since the only authentication is though p2p, big groups of wannabe cheaters would assemble under a decent coder/cracker and swap IP's/progs/modded clients to cheat. It is a very interesting idea though, p2p game server heh. Just a few complications I'd be worried about

Share this post


Link to post
Share on other sites

This topic is 4827 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this