Menu
What's new
RunUO Community

This is a sample guest message. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

Save core modification!!It's possible working on it..

N

noobie

Wanderer
@mrkroket:

it is easy to handle duplicate items with a simple saved flag.
the real problem which can not be handled is this:
a)while some method is executed:
-line xx: give some money to player A from B.
-line xy: give an item to Player B from player A.

lets say after the line xx, both player A and B saved, then line xy is executed..

if you reload the world, you will get a corrupted save in a sense..

about CRC:
it is almost same thing to evaluate that CRC with writing it. they almost take same time.
actually i explained it in my previous reply, what you are saying is actually a kind of hash function for serialization info. (see my previous reply)

@brodockbr: using a db for save is slower than using I/O. on the other hand, using xprevail which is a database persistance layer means you wont use binary data. it could take an hour to save the whole world, trust me on this :)

So overall, i think the most efficient way to improve current serialization would be:
writing save to memory could be an option, or increasing the buffer size which is only 4KB right now (actually i recommended it in another thread about serialization)

for both these options, another customized buffer could be used. using 20mb simple array buffer might not be a good idea. so you could implement a new buffer which is chunks of array.
 
M

mrkroket

Wanderer
noobie said:
@mrkroket:

it is easy to handle duplicate items with a simple saved flag.
the real problem which can not be handled is this:
a)while some method is executed:
-line xx: give some money to player A from B.
-line xy: give an item to Player B from player A.

lets say after the line xx, both player A and B saved, then line xy is executed..

if you reload the world, you will get a corrupted save in a sense..

about CRC:
it is almost same thing to evaluate that CRC with writing it. they almost take same time.
actually i explained it in my previous reply, what you are saying is actually a kind of hash function for serialization info. (see my previous reply)
Click to expand...


I don't think it's easy to handle duplicates and collateral effects. Like money, you don't destroy/move the item just change the amount, so you must track any amount change. The same could happen on other things, you probably end up tracking all changes on all vars.
Yes, it isn't a CRC what i'm refering, it's a cryptographic hash, a digest with low collisions.

Could the digest be useful? The thing is a to test how much the disk I/O affects to a save. The best way is to use two server replicas, one on HD and one on Virtual Disk. Take times of both saves and compare. Probably 85% of the time is used on disk I/O

And the 4KB buffer i think it really affects. Writing nx4KB chunks as a 20MB block is faster than all those chunks one by one.
 
A

Alis

Wanderer
as i said this project is opened source i gave all the things that must be done to work it what i gave are true and works i would be happy to see others exchanging their info on improving stuff on the save method i sended ..

Anyone who cares have suggestions or ideas they could either post it here or reach me from all the connection portals which i have 24 hour online maybe 2 - 3 hours sleep..
 
A

Alis

Wanderer
noobie said:
@mrkroket:

it is easy to handle duplicate items with a simple saved flag.
the real problem which can not be handled is this:
a)while some method is executed:
-line xx: give some money to player A from B.
-line xy: give an item to Player B from player A.

lets say after the line xx, both player A and B saved, then line xy is executed..

if you reload the world, you will get a corrupted save in a sense..

about CRC:
it is almost same thing to evaluate that CRC with writing it. they almost take same time.
actually i explained it in my previous reply, what you are saying is actually a kind of hash function for serialization info. (see my previous reply)

@brodockbr: using a db for save is slower than using I/O. on the other hand, using xprevail which is a database persistance layer means you wont use binary data. it could take an hour to save the whole world, trust me on this :)

So overall, i think the most efficient way to improve current serialization would be:
writing save to memory could be an option, or increasing the buffer size which is only 4KB right now (actually i recommended it in another thread about serialization)

for both these options, another customized buffer could be used. using 20mb simple array buffer might not be a good idea. so you could implement a new buffer which is chunks of array.
Click to expand...


Well what you talking about a memory thing is not a acceptable thing.. which both the system could be done without doing major madification .. maybe 100xtimes i will say this is a project based on a theory of object theory .. by editing only the main frame of the mobiles and the objects would be needed..

;) you will see in the further days which i will post the main frames modified done on the project.
 
A

Alis

Wanderer
you dont need to create a hashatable as beofore i wrote this please read it again.

I asume archive is iterativly getting objects from universe container using an Iterator therefore whenever he get a reffrence of an object and serilize an output to archive file and will ask next object from the universe container.Therefore after obtaining object from universe container even it is changed will not be disturb our mission.Assume that we freeze the system and made archive then unfreeze the system again and let the object be changed it is going to be same scenerio with our case. Asume that the archive will be completed only for this object and start with next object.

Im aware there will be some inconsistent case will be occured for those objects be archived and unarchived, the snapshot of the system at that moment will not reflect the real case.When we restore system from full archive and increments we will not achive the recent state of object that will be archived early and changed again till incremental archive is completed.But according to me this will rarely happend because we are talking about system crash and restoring.Also this can be acceptible because the object early archived has very limited possibility of occur.Even it happens it will loose the very recent change.

If we consider the current archive ; this scenerio cost more dramatically since you are going to loose last 30 min change in crash case(that needs to be restored, current user has a chance to complain about lost modifications on their objects).

For this reason I dont agree to use a secondary hashtable or so.What I am telling the archive can be started in background with in another thread(having lower priority) can run similtanusly and freezing is not necceserry.There is nothing to change but removing freezing process and just start archive in scheduled interval (in other word's nothing is needed to be changed but the operation flow going to be modifed).
 
Zippy

Zippy

Razor Creator
The frequency of world corruption on a "non-freezing" save will be much, much higher than you think Alis, especially for larger worlds which is the whole point of this anyways, right? Who cares if the server freezes for .4 seconds, we're talking about the ones that take 30 seconds to save when frozen

These could take minutes to save with a non-freeze method, and any time you load a world saved with this method you're talking about wide spread corruption. (Not just for crashes, but under any and all circumstances.)

Transactions would work fine/great/etc for a RunUO save, but the end problem is the same... something like that requires a major rewrite of nearly every script.

RunUO is over 200,000 lines, and I highly doubt anyone wants to go through and change every script file for a new system. Not to mention the immeasurable number of custom scripts affected... every shard would be facing huge amounts of rewrite just to allow their world to save.
 
A

Alis

Wanderer
Yeap its been two weeks since my last post on the topic is posted some guys said it was impossible some said your a women you wont understand anything about computer science bla bla bla.. My team whom working from several shard devolopers are asisting me with the new dynamic structure of the actuall save delta method . As zippy said before to let the files recognizee the new method we must highlight each line :) so we started looking analyzing how the main frame of the dynamic core is each team member is aware what to look and what to modify daily meetings are done and we are indeed and hopefully waiting in couple of weeks the release.

I hope that this will make things much more better then we are planing to..As for myself im very happy to asist the Runuo Community in such things.Whom ever wants to support us you know what to do thanks for the core designers of the runuo software.And also thanks for the people who are indeed supporting each other to bring the Runuo software better places.

Sincerly Alis
 
Mortis

Mortis

Knight
The thread appeared dead for almost a year. I am sure many would be interested in your project. Now we know your still around.
 
A

Alis

Wanderer
Well im still alive and im back. For the pm's guys i will send you the code modefications to use in your own hands because runuo will not use in the main structure its to late to that but its based on runuo 1.0 so if anyone interested in modifiying the codes on runuo 2.0 i will have to give the new modification based on netframe work 2.0

A.k.a Alis
 
U

unholy

Wanderer
I just wanted to say Good Job to the Runuo dev team .. It must be a real pain in the arse for you great bunch of peopleto spend your Valueable time effords an have all this to go through too My hats off to you ..



Thank you For your Time and dedication!
 
You must log in or register to reply here.
Top