How would an ASP .NET web application handle constant user requests?

Question

0.00/5 (No votes)

See more:

I want to make a text based MMORPG in C# and ASP .NET. The game will involve constant, continuous updates for example the character/skill experience a player has. My question is, how would I store/update those skill experience variables?

Would I update the SQL Server database every single time a change is made to the "experience points" variables or would I only update the database at certain time intervals? What state management would be best to store such data that is continously updating and is private to each user? How might the requirements/techniques need to be changed if the website/web application becomes extremely popular with heavy traffic?

Thanks for any input!

Posted 8-Oct-12 10:30am

FourCrate

Add a Solution

Comments

I.explore.code 8-Oct-12 17:30pm

I know its probably not the best parallel, but I am thinking the way chat applications work say on facebook. Basically, its a server socket program that's sat listening at a specific port, clients (aka gamers) connect to that server address and start sending messages i.e. playing game.

The server socket creates a tunnel directly with each client and also keeps a track of which clients are still in the game. Thinking of Texas Poker on Facebook. Once you have a sessioned tunnel created, you can use customised commands sent over TCP/IP to cause a certain action to happen. I would really love to see what others have to say on this.

FourCrate 11-Oct-12 17:47pm

Thanks for your reply :)

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Karl Stoney · Answer 1 · 2012-12-27T04:21:00

Depends on the hardware you have available, and the number of users you are going to have.

You *could* have a layer sitting in-between your app and db which stores certain things inproc and updates the db on a timely basis, but personally I would always update the DB when a change occurs, storing in RAM is dangerous as if your application crashes uncommitted changes wouldn't be there.

For high turnover applications I usually INSERT UPDATE or DELETE exactly when it is meant to happen, and then CACHE the READ's, to minimise the reads from the database.