Update - Disconnects and Latency Issues

Crashing channels =/= DDoS. Most of the time, the channels don't actually even crash, players just lag extremely bad and D/C themselves. Timing a crashing channel with a DDoS attack would be way too hard, and the people doing it would no doubt have a much more safer and not bring so much attention.

And I highly doubt it has anything to do with removal of hacked items.

This is probably someone who is being paid to do it, or they just want to see Nexon squirm and flail while they watch it.


Only way this could be for duping is if they're locking accounts, and this lag unlocks them causing rollbacks, thus duping.

It wouldn't unlock the accounts. To unlock locked accounts, you need the entire server to crash, meaning mushies reset, HT 30 man list thing gets reset, everything. Mushies aren't disconnecting which means its just immense amount of lag causing players to disconnect. The save cycle should get reduced though, that's the best way to prevent any duping at all, and right now its around 5 minutes I believe, which is plenty of time to do whatever you need.

The save cycle should get reduced though, that's the best way to prevent any duping at all, and right now its around 5 minutes I believe, which is plenty of time to do whatever you need.

Easier said than done. Every one of those saves uses enormous resources. There is a reason why the game doesn't save every second

Easier said than done. Every one of those saves uses enormous resources. There is a reason why the game doesn't save every second

I'm not saying to make it so it saves every second, but honestly thats one of the two ways to even stop duping in general. That+item IDs

I'm not saying to make it so it saves every second, but honestly thats one of the two ways to even stop duping in general. That+item IDs

They already have item IDs. They're not using them.

Every one of those saves uses enormous resources.

Not actually true.
It doesn't have to save every second either, just every transaction, and it needs to handle every transaction as a discrete unit, not individual parts that can be interrupted.

If it did that it wouldn't have to save every second, or every transaction, it could save on quit and not risk duping anything, it'd just risk data loss, not data duplication. That's the entire point of ACID design.

I'm not saying to make it so it saves every second, but honestly thats one of the two ways to even stop duping in general. That+item IDs

I'm assuming that 5 minutes was determined to be optimal in terms of cost & efficiency considerations, so I don't think they can/want to change that. It's actually pretty decent, I wouldn't expect it to be much lower than that anyway. Not for the massive amount of data getting saved.

I think they will eventually realize that they need to address duping head-on. Item IDs need to happen

Not actually true.
It doesn't have to save every second either, just every transaction, and it needs to handle every transaction as a discrete unit, not individual parts that can be interrupted.

If it did that it wouldn't have to save every second, or every transaction, it could save on quit and not risk duping anything, it'd just risk data loss, not data duplication. That's the entire point of ACID design.

My only concern here is that this would involve a complete re-design of the save system. While this method is far superior to the current, it isn't very achievable (considering how much Nexon LOVES change).

The Item IDs, while still a major revamp, would seem to be easier to implement. I don't think any other major issues (besides duping) arise from the current save method. Aside from the fact that it doesn't make sense from a logical perspective, I think the current method doesn't raise so many concerns that it'd be worth scrapping altogether.

It's pretty fascinating how the game has never actually gotten a major structural overhaul, considering how old it is.

oops. double post.

SC tomorrow at 10 AM EST, it seems.

OT: Nexon announced SC in game for 7 AM PST. No notice on site yet.

My only concern here is that this would involve a complete re-design of the save system. While this method is far superior to the current, it isn't very achievable (considering how much Nexon LOVES change).

The Item IDs, while still a major revamp, would seem to be easier to implement. I don't think any other major issues (besides duping) arise from the current save method. Might be missing something, though.

Yet again; The item IDs already exist and always have.
Adding them if they didn't exist is far more invasive than adding a transaction declaration at the begin and end of the save process.

You're at a handicap here if you don't understand the client server relationship or their database architecture so you should probably stop trying to explain how best to fix the situation.

SC tomorrow at 10 AM EST, it seems.

Seriously? Why not just take down the servers now T_T

Yet again; The item IDs already exist and always have.

Whether unique item ids exist or not is irrelevant by itself. When I say item IDs, I'm clearly referring to the existence of a check that verifies that there are no duplicates. I assume this check is not in place, or is otherwise not functioning properly, which is the only valid explanation as to why these dupes are occurring (assuming they occur in the way previously described in this thread).

As for the transactions... neither of us really know the full specifics of the client-server relationship in this case, nor how structural changes may affect different systems already in place. I'm sure you have more experience with this than I do, but at the end of the day this is all just speculation.

It's fun, nonetheless

Seriously? Why not just take down the servers now T_T

People wanna go home / waiting for Korea / etc. etc.?

neither of us really know the full specifics of the client-server relationship in this case, nor how structural changes may affect different systems already in place. I'm sure you have more experience with this than I do, but at the end of the day this is all just speculation.

You realize he's a pro DBA, right?

You realize he's a pro DBA, right?

neither of us really know the full specifics of the client-server relationship in this case.

Incase I was not clear... I'm fully aware that Eos' guess is a highly educated one due to his experience and knowledge, but the reality is that we do not know the specifics under which Nexon operates their servers, nor their database architecture. We've gotten some glimpses through the DB leak & general info from here and there, but nothing is ever for certain. Do you wanna debate that?

Whether unique item ids exist or not is irrelevant by itself. When I say item IDs, I'm clearly referring to the existence of a check that verifies that there are no duplicates. I assume this check is not in place, or is otherwise not functioning properly, which is the only valid explanation as to why these dupes are occurring (assuming they occur in the way previously described in this thread).

Let me put it to you this way

You have two options:
1) Every time an object comes into existence, you scan every single other object in existence, across hundreds of billions of them, to detect ID collision.
or
2) You don't commit saves until all steps of the save process have completed successfully, and if any point of it fails, you rollback the entire operation.

Which of those is more painful to do hundreds of thousands of times a minute?
Is it the one where you parse terabytes of data over and over and over? Or the one where you don't do anything but what you would normally do, with the added caveat that you do absolutely nothing at all if anything fishy occurred?

As for the transactions... neither of us really know the full specifics of the client-server relationship in this case, nor how structural changes may affect different systems already in place. I'm sure you have more experience with this than I do, but at the end of the day this is all just speculation.

I own a copy of one of their leaked DBs, and actually have the server infrastructure and training to use it, so I'd say I'm ahead of you on that one.

You realize he's a pro DBA, right?

A DBA who manages and specializes in the exact RDBMs they use, who has intimate familiarity with game design and delayed saving due to years of owning a MUD.

Let me put it to you this way

You have two options:
1) Every time an object comes into existence, you scan every single other object in existence, across hundreds of billions of them, to detect ID collision.
or
2) You don't commit saves until all steps of the save process have completed successfully, and if any point of it fails, you rollback the entire operation.

Which of those is more painful to do hundreds of thousands of times a minute?
Is it the one where you parse terabytes of data over and over and over? Or the one where you don't do anything but what you would normally do, with the added caveat that you do absolutely nothing at all if anything fishy occurred?

Question: using 2), wouldn't the server need to keep track of all such transactions until they clear? and then save them one by one? You mentioned saving on quit, but it would seem risky and a potential source for data loss, especially if there is a certain accumulation of transactions. You don't have to explain, but I'm quite interested, so feel free

PS: Sorry for sidetracking here.

Do you wanna debate that?

I clearly don't have to.

Question: using 2), wouldn't the server need to keep track of all such transactions until they clear? and then save them one by one? You mentioned saving on quit, but it would seem risky and a potential source for data loss, especially if there is a certain accumulation of transactions. You don't have to explain, but I'm quite interested, so feel free

The transactions are serial, independent of each other and occur in microseconds. They don't accumulate because the only thing they block is themselves. Two characters wouldn't block each other because they're not touching the same rows of data.

An example of how an item moves out of your storage bin into your inventory for example would be;

Code:

INSERT INTO ItemSlot_ETC
SELECT * from ItemLocker where
where characterid = 1 and accountid = 2 and sn = 99999;
GO
DELETE FROM ItemLocker where
characterid = 1 and accountid = 2 and sn = 99999;

The statements between the GO are handled as separate discrete events.
They complete as soon as you pass their semi-colon. If a crash occurs between them, voila, dupe.

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.

Removal of hacked gear = removal of megaupload/megavideo
Random group of like only 500 people (out of the over a million that play this game) that are major hackers = anon/4chan
Nexon servers = department of justice

Removal of hacked gear = removal of megaupload/megavideo
Random group of like only 500 people (out of the over a million that play this game) that are major hackers = anon/4chan

And that's where I realized you had no idea what you were talking about.

Some comments:

Those of you who are assuming the reason for these attacks is the removal of hacked gear, are forgetting we had the same thing happen long before Nexon touched that gear. Back then there was speculation it was because Nexon sued some people associated with a certain hacking site and tool.

These attacks are also not made for the purpose of duping. As several posters said above, DDoS is a very crude method of crashing a channel - if it even works at all. Dupers are usually able to find bugs in Nexon's server software, which cause an instant channel crash upon receiving a certain packet (or sequence of packets). They use these to time their duping crashes precisely and to crash one channel at a time. What we are seeing now just doesn't fit.

Eos is, of course, correct about preventing duping. It's a relatively simple matter of actually using the features the database product offers, instead of treating it as nothing but a glorified flat file. 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.