Update - Disconnects and Latency Issues

I'd also like to point out that the "item ID" method, besides being inefficient, does nothing against the duping of stacks and stacks of "rare" scrolls, recipes, or crafting materials.

Not true actually, if you can't duplicate the stack in the first place you can't unstack and reshuffle to hide the fact you've done it.
Stacking just prevents them from being able to spot duplicate IDs after the fact by merging everything into new IDs, but if it threw a PK constraint and never let the second item/stack exist it'd cut off the issue before it happens and could be hidden. That aside, the other flaws with a unique constraint on a DB this size still apply and make it potentially infeasible.

Stackable items have item ID's? Whatever for?

Stackable items have item ID's? Whatever for?

Because all items have IDs. It's a database, you can't just opt out of certain things generating identities. You have to have some unique way of identifying and referring to the object in memory after all, otherwise how would you tell one from the other? Just because they stack you don't suddenly not need to tell them apart.

Stackables have the most overhead, since they have to destroy one version and increment the counter of the survivor when merged, then spawn a new item and a new id when separated.

Because all items have IDs. It's a database, you can't just opt out of certain things generating identities. You have to have some unique way of identifying and referring to the object in memory after all, otherwise how would you tell one from the other? Just because they stack you don't suddenly not need to tell them apart.

Stackables have the most overhead, since they have to destroy one version and increment the counter of the survivor when merged, then spawn a new item and a new id when separated.

...was going to write a whole post of statements and questions about rowids and application ids and fields in tables and pointers to other tables but, bottom line is, the way Nexon set up their database is obviously nothing like I would have (I'm not a DBA. I've developed projects that used Oracle, but usually in a fairly trivial manner), so I'll not trouble you to explain it.

...was going to write a whole post of statements and questions about rowids and application ids and fields in tables and pointers to other tables but, bottom line is, the way Nexon set up their database is obviously nothing like I would have (I'm not a DBA. I've developed projects that used Oracle, but usually in a fairly trivial manner), so I'll not trouble you to explain it.

You also have to understand the DB is just a storage medium to them, all the real stuff is occurring in-game in RAM.
Since the DB is just a way to serialize the data they made it easily translatable to how the structures existed in memory so they wouldn't need extra overhead translating back and forth between good database design and good game design, since the two are not necessarily the same.

(btw, RowID's are unique to oracle, MSSQL doesn't have anything comparable and expects keys to be defined by the DBA, and even if they were using Oracle the game itself would not be able to keep track of the rowids properly in concurrency with with RDBMS making them functionally useless as pointers)

I always love it when Eos gets into these type of threads, I learn so much LOL

It's as simple as this;

Code:

BEGIN TRANSACTION
INSERT INTO ItemSlot_ETC
SELECT * from ItemLocker where
where characterid = 1 and accountid = 2 and sn = 99999;

DELETE FROM ItemLocker where
characterid = 1 and accountid = 2 and sn = 99999;
COMMIT TRANSACTION;

And suddenly the two are a single discrete block of logic. They both write their end results together, or not at all. Voila. Duping no longer possible.

Duping being possible at all is ridiculous.

Love how simple you've put it. It really is that simple, and yet from what I gather, Nexon hasn't even TRIED anything like this. What you've stated is a simple and routine coding/scripting practice to prevent things such as dupes and for avoiding interrupted/incomplete logic.

What you've stated is a simple and routine coding/scripting practice to prevent things such as dupes and avoiding interrupted/incomplete logic.

this is an understatement.
I've taught a 3rd grade class to write their own transactional DB and they did better than Nexon.

Uninterruptable transfers between tables is one of the most basic transaction concepts and is quite literally the textbook example of why you would want to use a tranaction.

Hopefully people looking at this and realizing for the first time exactly how minor of a change it is to enable this will better understand why Nexon is so poorly respected and why so many are so exasperated with them.

I was under the impression the desync happened because the tables weren't running on the same server, so when you crashed one, it lost its transaction queue and you still had a record of the insert, without the delete.

Wouldn't it slow down the game a bit if both servers had to complete the transaction before your item left storage?

That's not how database clustering works, and no.

Give me a bit and I'll diagram it for you.

This is the approximate of how it all works.

The database cluster is a series of servers that all act together as a single logical entity. They all have what boils down to the same info on them, and whichever one you talk to shares it's changes with the rest. All channels are sharing this single entity, they don't have to sync an independent DB per channel.

Each server is running 1 or more daemons. Each Daemon is responsible for listening on a single port and being a specific channel.

The daemon is where gameplay actually occurs. It's the logical (software) server, as opposed to the physical (hardware) server that's hosting the daemon.

If the physical server goes down, all hosted daemons (channels) go down too. That's why we kept seeing those 4 specific channels drop on Bera the other day, those were all serviced by the same physical box which kept becoming unreachable. You can also kill an individual daemon if you can figure out a way to make it perform an illegal operation and crash, which we've seen before.

In general principle the user/client never directly interacts with the database. You interact with the daemon and the daemon remains a middleman between you and the database to protect the database. This scheme limits an attacker to what they can coerce the daemon into doing.

As has been noted previously, each daemon only syncs with the DB at set intervals and during set events. Changing channels, logging on, logging off, entering MTS/CS, those are all triggers, and then it also has it's periodic saves.

Since the daemon is the one doing all the writing to the DB, it's the point of vulnerability. If you can kill the daemon before it finishes sending all it's commands to the DB, and it's commands aren't nested in a transaction to make them all-or-nothing, voila, duping potential.

I have learnt something today.

-snip-

So then what would Nexon need to do (assuming they would) to avoid such an exploit from happening? Or is impossible with the current setup? that exists now?

So then what would Nexon need to do (assuming they would) to avoid such an exploit from happening? Or is impossible with the current setup? that exists now?

I already covered that. It's very simple.

I already covered that. It's very simple.

Then why don't they do it? I think I finally understand what a pomegranate company nexon is




Probally wont stop me from playing sadly.

It's odd to me that the individuals who are behind the DDoS attacks haven't taken credit. In a lot of cases I've seen, hackers (not that DDoSing someone necessarily makes you a hacker) love to take credit for their "work". It also seems kind of odd considering everyone is apologizing to Nexon for complaining. I'm not saying they're not telling the truth, just that they could be even more transparent than they are. It's a start, at least.

Then why don't they do it? I think I finally understand what a pomegranate company nexon is

I think you answered your own question there. Unfortunately they are the company that makes this game we all enjoy playing/discussing, whether or not they are one of the worst companies out there.

Shouldn'y we direct our hatred on Wizet actually? aren't they the ones that do the programing?

I wonder how easy would it be to implement Eos code fix into the actual game structure. May that be what keeps them from applying it (regardless if it would save them a lot of trouble).

I wonder how easy would it be to implement Eos code fix into the actual game structure. May that be what keeps them from applying it (regardless if it would save them a lot of trouble).

What I typed was literally the extent of the changes required to implement.
That wasn't a figurative example. That was almost a dead on copy paste-able solution.

That was almost a dead on copy paste-able solution.

Considering Nexon's talent when it comes to copy and pasting, it is surprising that they are truly this incompetent. Oblivious and ill-informed, yes, but if what you said is all there is to it, it is beyond me why Nexon had not fixed this very large hole in their security.