Skip to content
This repository has been archived by the owner on Dec 26, 2021. It is now read-only.

MySQL implementation #84

Open
neves768 opened this issue Apr 26, 2017 · 10 comments
Open

MySQL implementation #84

neves768 opened this issue Apr 26, 2017 · 10 comments
Assignees
Milestone

Comments

@neves768
Copy link
Member

Posted by Lawliet (mtadayz) on mtadayz/MTADayZ#26

"I was wondering whether or not we could, somehow, use a mixture of tables and SQL instead of setElementData(). It may sound like that would be a lot of (unnecessary?) work, but since setElementData() is one of the main issues of MTA DayZ (and the strain it puts on both server and clients), it begs the question what alternatives we have.

My idea is as follows: As long as the player is online and playing, everything he does will be done via tables (table.insert, table.remove, possibly table.merge, ...). As soon as he logs out, everything in the tables will be stored in the SQL database (using either dbPoll/dbQuery/dbExec or executeSQLQuery). Once said player joins back, everything in the database will be written back to the tables. Of course, said tables will be clientsided and for the localPlayer only, to ensure no tables are being mixed up."

@neves768
Copy link
Member Author

pull request #82

@0xCiBeR
Copy link
Member

0xCiBeR commented Apr 27, 2017

The thing is, this can't be done that easy. This can become a potential exploit when storing all the values client-side. Rule N° 1 in anti hacking is don't trust the client. Any ideas on how to secure the tables?

@mtadayz
Copy link
Collaborator

mtadayz commented Apr 27, 2017

We could make the tables serversided, and generate a new key for every player (maybe based on their serial?), which could look like this playerDynamicTable[getPlayerSerial]. Any changes made by the player should be validated first through checking if the values match (like, if a player eats something, the value of the item he ate will be sent to the server and checked against the value provided in the table for nutritional values. If they do not match, abort further procedure).
Since most data sent to the client is just for displaying them (inventory, status icons, ...), we wouldn't have to worry about that in terms of security.

@neves768 neves768 changed the title [ENHANCEMENT] MySQL implementation MySQL implementation Apr 27, 2017
@neves768
Copy link
Member Author

using tables instead of elementData will save a lot of bandwidth and will decrease the chance of server shutdown by elementData exceeding the limit (Adding more players capacity)

@mtadayz mtadayz added this to the Version 1.0.0 milestone Apr 29, 2017
@1B0Y
Copy link
Contributor

1B0Y commented May 2, 2017

the server shuts down because of the amount of elementData exceeding a limit? Never heard that one before 🤔

@neves768
Copy link
Member Author

neves768 commented May 2, 2017

@1B0Y I saw it on 3 servers
In most cases, they have more than 100 players simultaneously

@1B0Y
Copy link
Contributor

1B0Y commented May 2, 2017

Huh, never knew. Changing everything over from elementData to tables would be a challenge and very time consuming, so you guys need to consider that and whether it'd be worth either updating the current framework we have, or going ahead with the new framework idea me and CiBeR had a few weeks ago.

@0xCiBeR
Copy link
Member

0xCiBeR commented May 2, 2017

As a plus, we need to add support for MySQL Tents and Vehicles.

@0xCiBeR
Copy link
Member

0xCiBeR commented Jun 5, 2017

@neves768 are you up for adding Tents and Vehicles to the MySQL System?

@neves768
Copy link
Member Author

neves768 commented Jun 7, 2017

@ciber96 only after 14/06/2017 (when I finish my week of exams and start vacations)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants