1

Let's say I have a server, where clients who connect are constantly updating their inventory.

I could simply save the changes in to the database after an item has been updated, or I could update the whole inventory after the client leaves the session.

If I go with the first approach, with my current specs, I can't process all those at the same time. If I go for the second, and my application for some reason dies, the updates are never stored in the database.

What can I do to solve this problem?

I can only come up with two solutions (both would imply checksums):

  1. Have a secondary application running, which simply creates a named shared memory. The main application will use this memory for the inventory of all the clients, and if it my application dies, then secondary application will keep alive the shared memory, and therefore the data, which can be saved once the main application is re-started.

  2. Map each client inventory directly to a unique file, like the shared memory. However, won't this slow my program? or is it fast as the named shared memory? (If I understand correctly, it should be as fast) (this is the one in my top list right now).

To be more specific about the second approach:

Is there a guaranty, in windows at least, that the following 3 approaches will be as fast in both write/read? If there's ANY KIND of delay,I need to know.

As far as I understand, even the file mapping approach will instantly update the memory, but not the file itself (which is fine).

// normal memory accesss
int *normal_address =            (int*)0x10203040;
*normal_address = 6;             //write: 0.00002sec (for example)
int get_value = *normal_address; //read: 0.000001sec (for example)

// named shared memory
int *normal_address =            (int*)0x10203040;
*normal_address = 6;             //write: 0.00002sec (for example)
int get_value = *normal_address; //read: 0.000001sec (for example)

// memory mapped file
int *normal_address =            (int*)0x10203040;
*normal_address = 6;             //write: 0.00002sec (for example)
int get_value = *normal_address; //read: 0.000001sec (for example)

NOTES:

Both approaches (memory mapped file and named shared memory) use these functions:

CreateFileMapping

OpenFileMapping
MapViewOfFile
  • The main application would be updated in a daily basis, so it can potentially end up with a nullptr or something that. The source code is a bit old and will be updated by multiple persons.

  • The secondary application would be created once, and never updated unless it's needed. Therefore there's no reason to believe that if the code is well written, no bug should occur in the future to make it crash.

THOUGHTS (ignore if needed):

Perhaps the secondary application could make backups of the data without syncronization: first retrieve the checksum, then get the whole inventory. If the checksum doesn't match, then it tries to do it again.

Perhaps another alternative would be to make the secondary application the one who actually handles the items.

  1. Everytime a client updates an item, the update would be sent directly to the second application, which would handle the update, and then store the update into the database once the client leaves. Since this application is really small, and it won't change, it's very simple to ensure it won't die. The main application however, will change constantly, which is the reason why it can end up with a null pointer being used by mistake or something like that, and suddendly die.
  • Or 3: Let the OS create a core-dump when your application dies. – tkausl Mar 12 '16 at 14:12
  • 7
    Can you explain why updating the database for every change is unfeasible for you? – Bart van Ingen Schenau Mar 12 '16 at 14:57
  • Too many item updates. I've tried it and there's delays, and since it's a game server, it affects the user experience. – Gam Mar 12 '16 at 22:41
  • @James You have either designed the schema incorrectly, or are using the wrong DB engine – TheCatWhisperer Feb 28 '18 at 14:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.