ok, since my Main PC fried tonight and the backup laptop ( a 8 year old VAIO T2 ) is unable to run DDO anylonger, I have emple time during my evening to answer the long way. ( I didn't have time at work... there's days like that where it sucks from the time you wake up to the time you go to bed... today is one such day for me )
Some Guy Here On The Boards wrote on Aug 17
th, 2014 at 4:30pm:
Whenever I hear about an account ban, I hear that a GM will 'log on' to the actual characters and manually delete/sell the inventory... This strikes me as odd. I know little of server / game / database architecture, but are not the characters, items, etc. all just data floating around somewhere on a server? Couldn't an admin account just 'delete' the data entirely, as simply as I delete a file off my disk drive? Or is the layout so different that such a thing is not possible? It would seem that if one could simply edit the data this way, it would have solved some of Turbines' problems... (thinking back on when they disabled buyback for all to prevent some from buying back the gm deleted items).
1) Oddity of GM having to log in to clear things.
Yes and know While they do it with Exxxxxxtreme Prejudice, they don't empty the inventory totally, being selective in your emptying cannot be done by scripts.
2) Char records and such are data floating on a server ?
Definitely. From my knowledge of DDO architecture, you have the frontend side :
74.201.106.53 Wayfinder [DE]
74.201.106.64 Ghallanda
74.201.106.56 Argonnessen
74.201.106.21 Thelanis
74.201.106.22 Sarlona
74.201.106.23 Khyber
74.201.106.59 Cannith
74.201.106.60 Orien
Then you have the backend side... Since my main PC died I can't give you the exact IPs until tomorrow when I'll be at work.
But they are in the 10.XX.YY.ZZ range ( so basically not routable ) and there's one for each server. You can find them by looking in the logfiles both in your user home dir and in the application data directory.
( there's also a nice logfile that details every option you bought for your account )
From my point of view that's two separate networks ( probably on separate interfaces ) and the backend network is also the network where the Database server is connected.
3) Data layout...
Well, that's a tricky one... Since we have no clue of the datamodel used for the database.
But it can be as simple as having everything tied to a character recorded in said character record...
to just pointers recorded in the character records that points to fixed records in other tables...
Example of the later :
Character Inventory Table
Item 0x00001 Qty 500 Slot Loc 0
Item 0x000F5 Qty 20 Slot Loc 0
Item 0xD0000 Qty 1 Slot Loc 1
In another Table :
Item 0x00001 Spell Component Power 1 : 0x00010
Item 0x000F5 Potion Power 1 0x00002
Item 0xD0000 Helm Power 1 0x00001 Power 2 : 0x000D3
In another table :
Power
0x00001 Haggling +3
0x00002 Jump +20
0x00010 Lvl1 Class Restriction : 0x00001
0x000D3 Intelligence +1
In another table
Class Restriction :
0x00001 : Cleric Only
Now you see the issue... it can be difficult to track down what data to erase.
So depending on the datamodel deleting an item can be as easy as deleting a record from a table, but it can also be something complex that requires lots of work to keep the integrity of the databases and tp make sure that the item gets deleted the right way.
Personally if I can do the deleting in a database through an UI of some kind, even if it's a clunky one and not really user friendly I'll still use it over doing it straight in the DB. ( I've done both at work... and while going straight for the data in the DB is faster, using the clunky UI had that "It's safe for the data integrity" bit that made it less stressful. )
Ckorik wrote on Aug 17
th, 2014 at 4:42pm:
Now *in general* the code they have in game has been tested and interacts with the database correctly - that is no one has ever tried to delete an item and ended up deleting someone elses item by accident -
in general is the important term here. Whatever you do, after a while inconsistencies will eventually crop up in the databases.
Things that losts ties ( just data ghosts that takes up place but are not tied to anything meaningful ), or things that changed when they shouldn't have ( because somebody did something he shouldn't have done, like making changes straight in the DB without going through the UI )
So yes, in general, things will work... That's how the first dupes occured... They used glitches in how the gamelogic scripts was ordering the database to write the data. That's also how the bag disappeared... the transfer script fired two scripts : first one to delete the item from inventory table, then one tp insert the item in the bank table. ( or the reverse )
Except that only the first query was executed... and the second one was interrupted for whatever reason.
That's where all the discussion we had about Transaction would have had a huge impact, beside making it extremely hard for Duping to happen, using transaction would have solved that issue.
Ckorik wrote on Aug 17
th, 2014 at 4:42pm:
I only say this because of actually seeing the results of past experiences when they have tried to do things from outside the game client itself.
I also agree, it's really safer for the game for Turbine to use the tools they have even with the limitations they have, than to dig straight in the database... Their displayed ability to work with databases makes me cringe, and wish they never ever encounter a data corruption like the ones I encountered at work... They would be unable to recover from it. And it would be a killer for the game impacted.
Ckorik wrote on Aug 17
th, 2014 at 5:15pm:
Going to go out on a limb and say they aren't using SQL for their database backend - based on the client files, and the issue they've had with duping, it wouldn't surprise me if they weren't using MUMPS.
They are using SQL, there's not really other option possible that has the required throughput with multiple concurrent queries without generating deadlocks.
Pages: 1
Question for Flav and others who know more than I (Read 3339 times)
