KonaMs and KonaDEV

[Kona]

~Ragezone~

Some of you might know me of my last project -*Konna Europe*-.
Now i am back and i will be working on two projects :

• KonaMs (Gms v83 in C#)
• KonaDEV v2.0 (Gms v83, based on MoopleDEV)

The progress of this project will be slow, however i will post a daily "bump" (or eddit my last post) with the progress that has been made.

About KonaDEV and KonaMs

Spoiler

Lets start with KonaMs:

Spoiler

KonaMs will be a GMS v83 PrivateServer , coded from scratch in C# .
Some Info:

• Will be Using MCDB. (MCDB tool will be released some day)
• MasterServer will hold the WorldServers.
• MasterServer contains all the information (Channel rates etc), All those info will be storaged in a "Info Database" (No stupid xml files that contains the info)
• MasterServer will be the only server connected to the Database, a total of 3-4 databases (MCDB,InfoDatabase,LoginDB,ChannelDB)
• InterServer packets will be used (No WCF)
• New way of Memory Manegment will be implented
• Lua Scripting will be used (first need to learn "lua" = 1 day.. )

It will be in v83 because Kevintjuh93 did a great work with getting all the OpCodes, and most of the packets.

This source won't be released, MCDB tool will be released.

KonaDev

Spoiler

This source will be a edited version of MoopleDEV.
I am doing this for the following reason:

• MoopleDEV is an awesome source (thnx to kevintjuh93), however there are things that i would change.
• I am seeing this as a great opportunity to learn Java
• This community will always stay at java, because it "works" . Even if things aren't being done on the best way. Releasing a C# or a C++ source will be only interested for a couple of people. MoopleDEV can become the perfect base for the people who stay at the "Java" community
• i prefer Netbeans above VS
• I am currently not "fixing bugs"

This source will be made public, Glithub will be added, every rev will be able to download from this post.

About Credits:
---------------------------------------------------------------------------------------
Even if above the class stays @author Kona, this doesn't mean that the code in this class is my "Copyright", It could be code from other sources, or code from the internet.
"@Author Kona" does only mean that i recoded that class, it doesn't mean that the code belongs to me and all Credits are going to the people who made the original code/ the code on witch it is based.

Progress KonaMs

Spoiler

• Done nothing

KonaDEV

Spoiler

Progress KonaDEV

Spoiler

• Made a small Lib that is currently Rev3

~Kona~

 

[kevintjuh93]

Re: KonaMs and MoopleDEV 2.0

MoopleDEV 2.0? You better get yourself another name. Thank you.

 

[Kona]

Re: KonaMs and MoopleDEV 2.0

MoopleDEV 2.0? You better get yourself another name. Thank you.

~kevintjuh93~

KonaDev -* So original *-

~Kona~

 

[kevintjuh93]

Re: KonaMs and MoopleDEV 2.0

~kevintjuh93~

KonaDev -* So original *-

~Kona~

It's better
Thank you very much and good luck. Though you do know in Rev121 a lot will be changed right?

 

[Kona]

Re: KonaMs and MoopleDEV 2.0

It's better
Thank you very much and good luck. Though you do know in Rev121 a lot will be changed right?

~kevintjuh93~

I am looking forward for it ^^ .
I am currently making a small library with C# tools , what i am missing in java ex (BitConverter,IDisposable,Console,DateTime,Converter etc). Will be Easy to add to a new Revision.

~Kona~


-31-05-2013-

• Made a small library with things that will be used in MoopleDEV rev121
• (For example, the PacketWriter will remove 4 classes)
• Implemented C# like event handling in KonaLib Rev2
• Made a small Java.exe Reducer (It simply reduces the memory of the Java.exe) Source code can be found in the Update Log.
• KonaLib rev 2 (See konaDEV Downloads), started to hate java.................

 

[Hilia]

Got some questions:
- Will konaLib be the base of a whole new server? or will it be implemented in MoopleDEV rev121? (it looks like the common dll of Vclarity , what is very nice)
- Shouldn't you make a new Development thread for the java project?

besides that keep going.

 

[TheIceBreaker]

v83 in c# wow i wish you the best of luck . Hopefully alot of other ppl[cough me cough] can learn from your development.

 

[Kona]

~update~

Working on KonaLib REV 3 (The Java thingy)

• Made a small TestLogin.
• Multiple connection support,
• Still need to eddit some things with sending packets.
• Still need to find out a way on how to call the GC efficiently.
• InterServer Packets still need to be tested.
• The C# Server will be Started next week

Tested the JavaMemoryReducer with the the TestLogin(2 connections)
(JavaReducer works on WindowsOnly and can be downloaded of the UpDateLog, i will recode it someday in C++)


~Kona~

 

[retep998]

Ah, another uninformed developer using winapi functions to pretend that they can somehow improve performance.
The only thing you're doing is telling windows to invalidate as many pages as possible from the process as possible. It does not actually reduce the total memory usage of the program, and the pages themselves are still in memory, just not associated to the program. This means the program now causes soft page faults whenever it accesses those pages. In effect your program does nothing more than look good on paper by making task manager report a much lower value, meanwhile it doesn't actually do anything of substance.
There is no reason to ever set the working set size of a process because Windows is already intelligent enough to page unneeded pages onto the hard drive when that space is needed for something else.
Maybe when you're learning C++ someday you can also learn something about how memory in a modern computer works.

 

[Kona]

Ah, another uninformed developer using winapi functions to pretend that they can somehow improve performance.
The only thing you're doing is telling windows to invalidate as many pages as possible from the process as possible. It does not actually reduce the total memory usage of the program, and the pages themselves are still in memory, just not associated to the program. This means the program now causes soft page faults whenever it accesses those pages. In effect your program does nothing more than look good on paper by making task manager report a much lower value, meanwhile it doesn't actually do anything of substance.
There is no reason to ever set the working set size of a process because Windows is already intelligent enough to page unneeded pages onto the hard drive when that space is needed for something else.
Maybe when you're learning C++ someday you can also learn something about how memory in a modern computer works.

~retep998~

I am very interested in this,
lets say: a program is eating up your ram, then your computer will start using Virtual Memory. In case you call "SetProcessWorkingSetsize(proc,-1,-1)" isn't that then reducing the ram used by the program, so your virtual memory and your ram will get "free"?. Afther that In case your program is unstable its ram will increase again?

Don't see this as a "I am smarter response",because i am not. I have never bother to learn how the way memory is handled. What i posted above is the way how i thought it works. (if the way above is the wrong way of thinking, then i would appreciate it if you could explain the good way).

~kona~


~1-06-2013~

• Added finalizers
• recreated the console class
• made a begin with the packets
• ClientSession is still bugged or the Encryption (probably both ^^)
• packetreader still hasn't been tested
• Currently not feeling to continue with java , starting with C# at 2-06-2013

~kona~

 

[oxysoft]

Why wouldn't you release KonaMS? I would be very interested in it. Thanks.

 

[retep998]

~retep998~

I am very interested in this,
lets say: a program is eating up your ram, then your computer will start using Virtual Memory. In case you call "SetProcessWorkingSetsize(proc,-1,-1)" isn't that then reducing the ram used by the program, so your virtual memory and your ram will get "free"?. Afther that In case your program is unstable its ram will increase again?

Don't see this as a "I am smarter response",because i am not. I have never bother to learn how the way memory is handled. What i posted above is the way how i thought it works. (if the way above is the wrong way of thinking, then i would appreciate it if you could explain the good way).

~kona~

There are several measures to the memory usage of a process.
The first is working set which indicates how much physical ram the process has access to at the moment. There is private working set which is pages of physical ram only that process can access, and there is shared working set which is pages that other processes can access too.
Then there is commit size which is the amount of pages that process can access in total on both the swap and on physical ram, but it excludes some pages which it merely has shared access to. Generally speaking commit size indicates the actual amount of space the program has allocated in one way or another.
Now, the concept of paging works like this. Whenever a process tries to access space from anywhere in its virtual memory (measured by commit size, not working set), the cpu uses page tables to translate the virtual address into a physical address. If the page is not part of the processes working set, then a page fault is triggered and the OS has to get the page into the processes's working set before it can continue. Soft page faults are when the page already exists on ram but just wasn't attached to the processes's working set yet. Hard page faults are when the page can only be found on the hard drive.
What SetProcessWorkingSetsize(proc,-1,-1) does is it removes all pages from the processes's working set, but it doesn't remove them from ram. This means that process now has to go through soft page faults before it can use those pages again. In addition, that space on ram is still being consumed by those pages, so it doesn't actually free up any ram, and if the OS really needs more space it has to go through the same paging to swap process that it would have to do anyway. In addition, the commit size of the process is entirely unaffected. The only way to actually reduce the commit size of the process is by actually coding the process in the first place to not bleed memory like a stuck pig, aka don't use java, or don't be such a terrible programmer.

 

[Kona]

Spoiler

There are several measures to the memory usage of a process.
The first is working set which indicates how much physical ram the process has access to at the moment. There is private working set which is pages of physical ram only that process can access, and there is shared working set which is pages that other processes can access too.
Then there is commit size which is the amount of pages that process can access in total on both the swap and on physical ram, but it excludes some pages which it merely has shared access to. Generally speaking commit size indicates the actual amount of space the program has allocated in one way or another.
Now, the concept of paging works like this. Whenever a process tries to access space from anywhere in its virtual memory (measured by commit size, not working set), the cpu uses page tables to translate the virtual address into a physical address. If the page is not part of the processes working set, then a page fault is triggered and the OS has to get the page into the processes's working set before it can continue. Soft page faults are when the page already exists on ram but just wasn't attached to the processes's working set yet. Hard page faults are when the page can only be found on the hard drive.
What SetProcessWorkingSetsize(proc,-1,-1) does is it removes all pages from the processes's working set, but it doesn't remove them from ram. This means that process now has to go through soft page faults before it can use those pages again. In addition, that space on ram is still being consumed by those pages, so it doesn't actually free up any ram, and if the OS really needs more space it has to go through the same paging to swap process that it would have to do anyway. In addition, the commit size of the process is entirely unaffected. The only way to actually reduce the commit size of the process is by actually coding the process in the first place to not bleed memory like a stuck pig, aka don't use java, or don't be such a terrible programmer.

~retep988~

Spoiler

Thank you for your explanation, now i am wondering are there things i missed about knowing of "incode".
(So the actually code of your application):

• 
  [*=1]The Stack
  [*=1]The Heap (the Low heap(small objects) and the "Large" heap(big objects)).
  [*=1]How the GC works.
  [*=1]That you need to pass by references
  [*=1]That you need to null ("delete" c++) objects you don't use.

~Kona~

Why wouldn't you release KonaMS? I would be very interested in it. Thanks.

~oxysoft~

Maybe i am just like the person who released MapleGame (first saying he doesn't release it and later he does).

~Kona~



~2-06-13~
*Nothing will be done today, don't got much time.

~3-06-13~
Didn't feel to do anything... (Did Download MSSQL Manegment and thats it)

~4-06-13~
Made a auto Query executor in the database DLL.


~Shame post of 6-06-13~
I am not feeling to continue this for now ..., again -*Shame*-, However this is the code that has been done.

• There should be no Memory Leaks, In case someone dc's press "Enter" on the MasterConsole and you should see "ClientSession Killed". If this isn't the case = Memory Leak
• Not all Errors are handled correctly in the KonaData.DLL
• Using MSSQL , All data about channels etc has been stored in the ServerDB , Queries are in the download link.
• KonaCore.DLL config = KonaConstants
• Kona (KonaMaster) Project Config = Config class.

~Kona~