Jump to content

Offloading to more server


Recommended Posts

If I can add my 2 cents and my experience. We have tried this before with both Mangos and another emulator. Unfortunately you will most likely end up with either items going missing, or at least with the server mail system going haywire. Please see my post here: http://getmangos.eu/community/viewtopic.php?id=5973

Although this method does work, as you have discribed, it unfortunately creates bugs. You can even take it a step further, the "raid realm" does not have to be on the same LAN, it can be made to work remotely as well, from another location.

Good luck, and if you managed to get this working without mail erros or items going missing, please do let us know what you did.

Link to comment
Share on other sites

  • 39 years later...

First of all, its going to be stoneage practice but if anybody want to try or disscus, so be it.

About minute ago , an idea hit me how to very basicly offload your players to a different server and forces them go there. 1st server will be runing whole world kalimdor, outland,.... and 2nd one will be runing only raid instances. How ?

2nd server will gona have exactly the same mangosd installed as fisrt one, when 1st one updates, 2nd updates too. He needs also have a access to characters and realm database. 1st server will be wiped out of raid instances and blocked from the inside of enternace (so when players enters the instance they canot move anywhere) becouse if they can, they can use it to exploit and skip a lot of bosses. So they will be forced to change realm to realm of 2nd server aka "raid instances server" So who ever is inside instance can see spawned npcs.... It is quite recomenede to wipe outside world, and block as much innkeeper and places as could be, so they cannot expolit it. Party will not gonna survive throught relog, so only raid instance can be (from instances)

By this method you can offload raid instances , outland , northrend , kalimdor , kingdom. I know its not a perfect, its a very brute method. But its only one that can be done right away by simple mortal who is reaching limit 2k - 3k+ luzers online.

Yeah, and btw , spare me coments like "it's a dumb idea" I know that it is.

Answer to 2# post

This has nothing to do with architecture. You absolutly do not know what I was writing about. I'm talking about 2 independent servers running their mangos daemons, they have just common database for characters and realm. And at some point, player will just do log off, change realm to another, and he can continue. Why? I have that described up in article. I'm not asking for anyting, I'm just telling how it can be done without coding a single line.

Answer to 3# post

Yes I know that I will need 2 of them, that's the point of offloading and I already mentioned it in topic title and in post, but thank you for pointing the obvious. And you will not have a serious problem in char DB, becouse it's not possible to log twice on same account. Servers will be on lan (that's obvious). So I don't see how it will be possible to have a problem with characters database. We are only duplicationg mangos databse on our 2nd server.

Answer to 4# post

We all know that offloading is not a new idea, we are not discussing offloading by it self but how it's done is new. And you are wrong, I did not find any post how to offload by my way. Every post about offloading is about coding and so on. And you are wrong if you are talking about this exactly method. Blizz is offloading interactive their server. Not "blocking" users and forcing them to relog to a new realm.I'm writing about manual offload. Thx for posting.

Answer to 5# post

Ok , again, try this time to actually read, what i wrote and this time, understand. Clustering is totaly different and on much higher level ,what I'm talking about here. You want to offload your way ? Ok, why not, do it, go code.... If'm going to offload, I'm going to do it my way ,without a single line of code to add. Just read the proposal. You are talking about totaly different thing, but basicly the same. I'll try to explain it to you what I mean by some sort of lower level understandable to you. Player log in to server1 (physical server numero uno) which is running mangos numero uno too. He plays , do stuff, and than want to go to raid instance with friends. So they form a raid, enter instance, but hey, instance is wiped out, and they cannot move anywhere. So they log off from this server, in they client they choose option "change realm" and they log to our raid instance server (which is server numero duo , with running mangos numero duo). They share the same characters \\ realm database. But have different mangos databases (which needs to be at the same point). So we just offloaded players from our 1st server to our 2nd server. Now try to explain to me, at which point you need to add some sort of code, becouse from my point of view, you totaly do not get the idea.

Proved by "live" server , thx to post 7#. No need to let it open anymore. I also tested it by abou 5 people with no problems, so i needed a bigger proof of concept.

Out of date:

Go on people. Anybody want to prove that I'm mistaken or that it's a bad idea.

Link to comment
Share on other sites

For that sistem to work you will need 2 servers using the same charasters db which is not good. It can lead to some sirius problems whit the char db. The only way yo make it working is to have a script that will copy the changes on the 1 char from one characters DB to another characters DB when that char exits one of the realms. If that is even posible.

Sory for bad english

Link to comment
Share on other sites

Proved by "live" server , thx to post 7#. No need to let it open anymore. I also tested it by abou 5 people with no problems, so i needed a bigger proof of concept.

Out of date:

Go on people. Anybody want to prove that I'm mistaken or that it's a bad idea.

Well we tested it with about 50 people on the first realm, and about 20 on the "raid Realm", although it did work in concept, it did create problems with the mail system, mail simply stopped being delivered because it was seen as duplicates by the server, and simply got deleted. This happens as soon as you log into either of the realms, after a few minutes (I guess when the server does a periodic data update) a lot of "duplicate error" messages can be seen in console, and then the mail is gone.

We shut down the raid realm after about 3 days because of the mail system conflicts. I would assume this could also happen to items, although none such problems were reported. So like some comments here say, it does work to a limited degree, but there will be problems. I guess it depends on what your needs and expwctations are, whether you do this or not.

Link to comment
Share on other sites

From what i can tell the mangos "world" executable does all the work - including "delivering" mail - the mail is stored in the characters table and thus creating a problem when both servers are attempting to "send" the mail.

In the "2 servers" version the players on the second realm will not be able to chat with the rest of the world - like "LF1M MainTank BT" :eek: - a chatserver needs to be implemented to to that

So a functional world cannot be made with unmodified mangos.

The only way seems to be to have separate dedicated aplications: world - chat - instance - arena(?) - battlegrounds(?)

The instanceserver should not do anything else but instances (arena and battlegrounds can be included in this category) and players who are not in an "instantiable" map are to be "ported" to the same spot on the worldserver.

The worldserver should do whatever is doing now, just do the opposite "porting" to the instanceserver.

Now to send+receive chat from the chatserver that communication should be handled by both (world + instance) servers (through the chatserver so messages arrive in both servers regardless from where they were sent) :P

Link to comment
Share on other sites

Funny thing ^^

I tested such a scenario in the first half of 2008.

It worked pretty good...

Item creation on one server leads to no problems on the other one.

But I have to admit that there were no tests with the mail system... and I have no clue why item creation or more general operations on the item_instance table work without problems but mail doesn't.

Our problem was - as you discribed - that chars could enter a fully spawend instance on the "raid realm", switch to the other on, walk the hole instance to the boss position, switch realm again and.. well skipped all the trashies.

Thats why we dropped the scenario.

BUT it just got to me ;)

Again very dirty an VERY risky...

Despawn all gobjects you can access the mail-system with.

Auction-NPCs should also be despawned to be on the "safe side" ^^

AND to avoid the enter instance/switch realm problem...

Write a creature with EventAI that uses some spell like "Hand of Death" or any other STRONG instant kill spell and spawn your instances will with this creature (simply replace by one MySQL Query all mobs on any maps except 0,1,530 in the creature table with this mob - saves time)

No one will switch realms anymore ;)

And concerning the chat... well, in instance my for myself.. I turn any chat off to have my peace an fun. Trouble can be handled by your other GMs during that time, take a for yourself breake ;)

And the community... they should search for players on the "level realm" and change whenever the group is ready. Don't see any problem with it just discipline.. not your problem ;)

And as thread starter said I repeat again:

That's all untested and very risky, YES, I think we know.

Save the "good luck you fools"-posts for someone who realy deserves it.

Link to comment
Share on other sites

Funny thing ^^

I tested such a scenario in the first half of 2008.

It worked pretty good...

Item creation on one server leads to no problems on the other one.

But I have to admit that there were no tests with the mail system... and I have no clue why item creation or more general operations on the item_instance table work without problems but mail doesn't.

Our problem was - as you discribed - that chars could enter a fully spawend instance on the "raid realm", switch to the other on, walk the hole instance to the boss position, switch realm again and.. well skipped all the trashies.

Thats why we dropped the scenario.

BUT it just got to me ;)

Again very dirty an VERY risky...

Despawn all gobjects you can access the mail-system with.

Auction-NPCs should also be despawned to be on the "safe side" ^^

AND to avoid the enter instance/switch realm problem...

Write a creature with EventAI that uses some spell like "Hand of Death" or any other STRONG instant kill spell and spawn your instances will with this creature (simply replace by one MySQL Query all mobs on any maps except 0,1,530 in the creature table with this mob - saves time)

No one will switch realms anymore ;)

And concerning the chat... well, in instance my for myself.. I turn any chat off to have my peace an fun. Trouble can be handled by your other GMs during that time, take a for yourself breake ;)

And the community... they should search for players on the "level realm" and change whenever the group is ready. Don't see any problem with it just discipline.. not your problem ;)

And as thread starter said I repeat again:

That's all untested and very risky, YES, I think we know.

Save the "good luck you fools"-posts for someone who realy deserves it.

The reason the mail system doesnt work with 2 servers running off the same char DB is because mail is saved in memory until the server shutsdown. When 2 are running at the same time, thats 2 different places in memory its being saved and it gets confused as to which thing it should write where.

This should be a rough sketch of how it works. It's what I picked up from different scattered converstions atleast.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use