> > 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]>
