Session Application Vs DB only Base application

[leZourite]

Hi i am new to this forum, though i've came a bunch of time !

The question is in the subject, i am wondering for a game (and the complexity involved) if pulling from the DB everytime a paged is refreshed is very performance efficient instead of storing anything needed in memory and make DB calls only when writing to the DB ?

Example : say you have a dashboard "? la" robowars.com, the thing is neat, but as it works stateless, every refresh => reload the dashboard from the DB, of course on SQL SELECT, if i am not wrong mysql does query caching so the user is pulled from the cache instead of the whole DB...

Now if the whole thing was build on the fly by first storing all the characters status in a session, and then the dashboard would not have to be pulled from the DB at all,and with a class of some sort that take the user id as parameter, we could invoke methods such has storing bank/training etc etc...

If think that the second choice, while "'worse" on the memory side prevents DB I/O bottlenecking if a lot of users are playing at the same time. Anyway a game of this sort wouldn't play on a shared host, most likely a dedicated server..

What's your thought about that ? most applications/games uses stateless (ie DB calls every pages even if there is no action taken) and then when the game gets slow they just upgrade the server (while i think to a certain extent should be done at one moment or another) and i think it's a bad practice fixing bad application behaviours with hardware upgrades !

Regards

PS: I am French, please bear with me if my English is far from good

[dvd871]

Well the short answer is that sessions are not secure and the data can be altered and possibly viewed by other people than the data was meant for.  If you get a chance you should get the php docs and read the sessions portion.  A little research on google about php sessions will also give you some details about session security.

[leZourite]

Well... actually I know what is Session Fixation, and how to possibly limit/prevent this :

- Prevent XSS
- Enable Cookie_Session only
- Filter any Input
- Token in session with information about the referer or whatnot, stored in the database and challenged by the session to see it's right
- Session ID regeneration at each login/relogin, adding another login step in case of sensitive data modifications (admin panel... etc etc)
- And if i want to go hardcore, i store all the sessions in the database ! but it's about game and not the defense website we are talking about

Now that doesn't mean it's unhackable, but will prevent most script kiddies to do any harm ....

So the problem here discussed is not about "sessions" is not secured, but if storing all data from a player at login instead of pulling it off the Database as 99% of existing games do is better on the performance side Wich i believe, but i would like to have some thoughts from some coding gurus

[codestryke]

The reason many people don't do this because you are forgetting the multi-player aspect of the game. As an example, you have your data cached into a session, I attack you and you lose some thing from that attacck. At what point do you query the database to get the newly updated information about me attacking you?

Yes you do get certain information on every page hit, however, the performance drain is very minimal if the query is created properyly, if it's index properly ect. mySQL is FAST and I mean fast and has very little performance drain when doing SELECT statements. It's the updates / inserts that are going to drain you db resources more then a query on each page.
 

[leZourite]

Now that's what i wanted to hear ! =)

Yes i agree i forgot the multiplayer part.. if someone beats my character to death due to the session caching i won't have realtime information that i am dead !

I had some concerns but if the read is that fast i suppose that's the way to go !

Thanks for the answer, i wasn't sure, my buddy was right (though he didn't give explanation this way )