Okay, so let's say I'm a script kiddie with a bug up my butt about your web server. I decide I am going to take it down. Now I'm smart enough to know that servers are multi-threaded, meaning they can host lots of connections and process threads to manage simultaneous connections. But what I am banking on is that your server does not have any limits on how long a process can stay open.
So what I do is craft an application that continuously opens processes that will take forever. All the well behaved processes from other users will eventually finish, leaving one more process thread for my malicious app to gobble up. Eventually my malicious app gobbles up ALL the available processes, and bobs-yer-uncle I have your server by the short hairs. Oh but wait! Turns out you were not as dumb as moi hoped you were, and you set up policies on your web server that automatically terminated processes lasting longer than 30 seconds. Well I might be able to bog down your server, but I can't kill it. Oh but wait! You turned out to be MUCH smarter than I thought, and after my server terminates x number of processes from a particular address, you lock me out of your server! Okay, well I craft my program now to create HUGE processes, as big as I can get them. Oh but wait again! Your server has limits on how big a process can be! Dang! Yer a genius and I am screwed! Bob On Aug 4, 2010, at 9:59 AM, wayne durden wrote: > Thanks Andre, and I am working through your article now as well. I get that > it is per process but the part that isn't still clear to me is that the OS > can be doing my intensive process for 30 seconds before closing it and also > attending to another user simultaneously or not. I am under the impression > there is still some resource slicing going on, I just don't have a concrete > understanding... > > This is all very interesting to me because I am interested in moving a > desktop app that processes datafiles up to 100,000 lines which can mean for > each line comparing against the remainder (in reality sorts cust this down a > great deal), but this can run for minutes on a desktop app and I have got to > cut it down into asynchronous processing as per your article... > > Thanks! > > Wayne _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
