I've done a bit of thinking and came up with a mechanism that might solve both issues of wasted memory and "lost" users. It involves persistent storage of "retired" sessions, so if this is actually how LRUMap or the session Manager works, I apologize.
Basically, we should mimic a virtual memory type of mechanism. If a session has not been used in a long time, we can store it out or "retire" it to file system, dbase, ldap, etc... In that way, we get some RAM back and do not "lose" the session. If a request for a session that is "retired" comes in (like a page fault), we can retrieve it from disk. Granted, this is more complex, and we face a possible new attack (requests for retired sessions that are actually very very old or invalid). In addition, a "session request fault" is not guaranteed to have enough memory to bring the session back in. Thoughts? Regards, Michael ----- Original Message ----- From: "Michael E. Locasto" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, June 18, 2002 7:40 PM Subject: Re: [PATCH] When Session Max reached, throw out oldest session > > > > Sessions, or server memory, is a limited resource. So no matter how > > you slice it your bar isnt going to be able to please everybody. This > > proposal/patch allows the sober guy to enter and escorts the had too > > much guy out. > > Not to stir the pot, but this is a bit of a false analogy. The phrase "had > too much guy" is misleading. If a guy is drunk, it's a good idea to kick him > out of the bar so he doesn't damage your bar. But, if I'm the user who has > been entering data on a really long webpage or carefully choosing academic > courses during registration or just walked away for a cup of joe, I don't > want to come back and see myself kicked out! > > To engage in analogies of my own, the new user isn't a paying customer yet - > we don't know if he's just there to shoot the breeze or buy drinks. On the > other hand, our drunk will probably keep on drinking until he passes > out...he's invested in us, that means we should invest our service in him, > not some guy outside the door. > > > Interesting... well the DOS attack would constantly creating new > > sessions... but active users of the site would, because they are > > using the site, would be moved up to the top of the LRU, so the least > > used sessions would be ones being deleted... which would probably be > > the ones from the DOS program (unless it was smart enough and had > > enough memory to keep track of all the sessions it was making, and it > > refreshed its cookies/sessions at the right times..) So depending on > > the parameters and rate of DOS, this algorthim might actually reduce > > the effect of a DOS attack. > > The attacker doesn't need to keep track of it's sessions, just make new > ones. I think an attacking program might be a bit faster than a human > reading a webpage. By the time the "active users" get down to the bottom and > click on submit or whatever, they have been pushed to the bottom of the > stack, with all those nice empty attacker sessions sitting on top. So, I'm > not sure this would reduce a DOS attack. > > This is a tricky call. > > Regards, > Michael > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
