Skoodge wrote on Jul 22
nd, 2020 at 4:41pm:
That the server problems might be related to them trying to stop the duping? If the dupe method relies on interupts or logoffs, they might have tried to add a protective protocol and fucked up their own servers in the process.
Interesting notion.
I ( we ) know that there's a frontend and a backend side for each server. ( as noticed by Techno here :
http://www.ddovault.com/cgi-bin/yabb2/YaBB.pl?num=1461363393 after one of my post. )
From the same post we can see that on the frontend side there's different IPs for different things ( even if physically they may all end up in the same virtual server ).
We only have hints of the backend side with the login queue and the status server IPs, but there's also probably a database server for each game world. ( along with an O&M server, a log server and a few other
servers )
My understanding of the current dupe method is that it's using the fact that the database content is updated sequentially with a delay and if timed right some of those updates are discarded by the shutdown.
The best method to get rid of the duping is to dump everybody ( kick all the players out ) and force a database queue emptying but that can be annoying if it's not automated and/or if there's no tool to perform the database queues flush ( especially if there's a queue per character/user... which would make it a pita to do )... you need a guy to do it on all the servers. ( and that guy needs to know what he's doing ).
Now add to that the fact that apparently the backend notwork seems to be common for all the game servers, and you have the recipe for some nice fail.
one thing they could try to llimit the latency between the database and the game world is to separate the database transaction network from the main back end network and to upgrade it... and to separate it on a game world basis... since each game world has it's own database server and everything is supposed to be virtualized, they could host the game server and the database server on the same physical hardware using the internal virtualizer network switch for added bandwidth ( instead of going out to a physical network and another box ). But this requires some devious and nasty optimization on the virtual machine side.
If not done correctly all the data writes in the database files would impact every virtual machine hosted on the physical server ( concurrent writes on the physical HDD. [ because it's probably not SSD, but a RAID5 array or something sdimilar ] ), creating lag, long loading screens and more... ( which strangely is what we see )
TLDR : I think they tried something with the database servers in the backend, namely hosting them on the same physical host as the game world, to limit the
duping cases, and fubared it, because they didn't take into account the DB writes.
As for LoTRO... Remember it's exactly the same game as DDO when it comes to backend and server setup the only difference is in the universe. ( the DAT files used by the game client. [ hell it's also exactly the same setup that was used for AC2 ]
The games were devlopped concurently and in the early days things added to DDO were added later to LoTRO ( we beta tested lots of things for them that way ).
Nowadays it's more LoTRO that beta test things later added to DDO ( because there's more money in LoTRO to develop things... and once developped, since the games are identical, adding it to DDO is cheap and easy )