Well at the beginning in the private and even the public beta stage we''re not going to have that many people so it will give me time how to handle more clients logged in.

ALL YOUR BASE ARE BELONG TO US!!!!

The 570msec is only the actual loading of the file. Once in memory it takes 0msec to send everything where it needs to be. I use async messaging for everything.

The server doesn't do anything but handle DPlay messages. The only additional thread I could potentially need is for file i/o.

570 is actually high. It will be around 100Msec with a minor fix. Which isn't too bad. It's only done once per login.

*edit*
The 570Msec comes from using a computer on the network as a central database over a slow line (10Mb). I tried it locally and it loaded a player in 0MSec. So I'm fine.

The server stress test will happen in a week or less. We just have some minor details to work out. I'll post the results at my site.

Ben
http://therabbithole.redback.inficad.com
http://www.vendettaonline.net

Edited by - KalvinB on February 20, 2001 7:40:43 PM

Another solution would be... any data that needs to be saved gets written out to a flat file, in some format that makes sense to you. Another process reads that data file and saves the data to your database (mySQL, MS SQL Server, whatever).

Game On,

Dave "Dak Lozar" Loeser

Um that seems like it would take more processing power to do then for the computer to just do it automatically without putting it in a file then into the database but just do it into the database.

Kalvin just remember that when c++ opens a file if it crashes you''ve lost your file remember that! I can''t have that happen in my server!

Sure a SQL server won''t be the fastest solution, but assuming you''re multithreading, a piece of software that supports transactions, rollback etc... is priceless IMHO. Of course you can write your own, but I can see a good custom database application taking at least 2 weeks to a month of dev. time.

The server opens the file, reads it, closes it. The only file open the whole time is the log file. Everything else is in memory. When a player exits the server writes their information back to their file. open, write, close. All in less than an Msec. Only those players who are on-line have their files in memory. Everyone else just stays on disk.

Also, I have yet to see my server crash. The client hasn''t crashed in a good month. When a bug comes up I stop everything else until it''s fixed.

Ben
http://therabbithole.redback.inficad.com

Besides the hastle and overkill to use Mysql is it really that slow with connection pooling? Does it really take that much longer to save data to a mysql record compared to updating a file? What it be a very bad idea to keep world information such as persistant maps in a database? The maps would of course be loaded into RAM when the server starts. I''m no expert and I''ve been trying to find answers to these questions. Any experience or tips would be appreciated.

quote: Original post by Dak Lozar

Another solution would be... any data that needs to be saved gets written out to a flat file, in some format that makes sense to you. Another process reads that data file and saves the data to your database (mySQL, MS SQL Server, whatever).

I will elaborate...

The file that you write to, would be on a fileserver (ideally), the process that reads this file and places it into the database would run from another machine –

What this serves as is a back up to all that has taken place in the game for a period of time, in the event that the database is corrupted before a back up of it can be performed.

I realize that your game isn’t meant to be commercial and that you probably do not care if you lose players data… but in a commercial setting, where people are paying for their play – you better have back ups!


Game On,

Dave "Dak Lozar" Loeser

yeah don't worry we'll back up every couple of days or so. Also I think i have a way to make it so if we have a time warp you still have the same skills,stats,items, etc.. and only your position is reset to the last save spot!

p.s. LOL MATRIX didn't see that you knew what i meant by "All your base are belong to us" LOL nice

Edited by - kalldrex on February 23, 2001 1:13:01 PM

IMO SQL is excellent for storing server-side data for MM games. It may incur a bit of a cost (potential administration issues plus cost of software if you aren''t using MySQL) but provides a number of benifits, the most significant being transactions. While a custom flat-file solution might turn out to be faster for small servers, problems arise when concurrency becomes an issue. Having a cluster of servers all try to operate on a single set of data becomes problematic with a file solution. SQL enforces business rules and provides transaction and rollback support right out of the box. And it''s incredibly scalable. And can be extremely fast, provided you design everything properly.

Simple answer: yes, SQL is good. And MySQL is free. Definately give it a look.