Way to limit total number of sessions from one IP address

[tbone]

In trying to improve the throughput of a classic ASP app I wrote last
year, I added monitoring to the application and session start and end
methods. For one, I'm counting the total number of sessions and the
high water mark. My monitoring has revealed a few interesting things.

1. The ASP application is being shutdown and restarted almost daily.
The hosting company swears that neither the machine (shared server)
nor IIS nor the application is being restarted. Is there any other way
the Application_OnStart and _OnEnd methods might be invoked?

2. I found in the app log that apparently one invocation of the app
was being shutdown while a new one was being started; i.e. the Startup
event for the new run was logged before the Shutdown Complete event
was logged (in the same file) for the old run. How is this possible?

3. At one point, about 40 new sessions were started up from one given
IP address, with 5-10 seconds between start events being logged. Does
this happen if the user has his browser's cookies disabled? How else
might this happen (except perhaps for deliberate DoS-style hacking)?

4. Because of (3) above, I think I want to limit the number of
concurrent sessions originating from a given IP address (I already
keep an application-level array that tracks the IP addresses of all
active sessions). To be least annoying to the end user, I presume I'd
want to kill older sessions rather than not allow newer sessions (in
case of browser crashing, for example). Is there a way to kill another
session by ID, or to instruct another session to kill itself?

Thanks
tbone

[Larry Bud]

> 3. At one point, about 40 new sessions were started up from one given

IP address, with 5-10 seconds between start events being logged. Does
this happen if the user has his browser's cookies disabled? How else
might this happen (except perhaps for deliberate DoS-style hacking)?

4. Because of (3) above, I think I want to limit the number of
concurrent sessions originating from a given IP address (I already
keep an application-level array that tracks the IP addresses of all
active sessions). To be least annoying to the end user, I presume I'd
want to kill older sessions rather than not allow newer sessions (in
case of browser crashing, for example). Is there a way to kill another
session by ID, or to instruct another session to kill itself?

I think limiting the # of sessions is a backwards way of fixing this.
There's no reason your app should be shutting down in the first place.

But if you insist, the only way I can think of it is to save IP address
and Session ID in a database on the home page.

Then on each subsequent page, you need to check to see if they still
match. If they don't, a newer session has been introduced, and you
could push the user to a "session timed out" page.

[Roland Hall]

"Larry Bud" wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...
:> 3. At one point, about 40 new sessions were started up from one given
: > IP address, with 5-10 seconds between start events being logged. Does
: > this happen if the user has his browser's cookies disabled? How else
: > might this happen (except perhaps for deliberate DoS-style hacking)?
: >
: > 4. Because of (3) above, I think I want to limit the number of
: > concurrent sessions originating from a given IP address (I already
: > keep an application-level array that tracks the IP addresses of all
: > active sessions). To be least annoying to the end user, I presume I'd
: > want to kill older sessions rather than not allow newer sessions (in
: > case of browser crashing, for example). Is there a way to kill another
: > session by ID, or to instruct another session to kill itself?
:
: I think limiting the # of sessions is a backwards way of fixing this.
: There's no reason your app should be shutting down in the first place.
:
: But if you insist, the only way I can think of it is to save IP address
: and Session ID in a database on the home page.
:
: Then on each subsequent page, you need to check to see if they still
: match. If they don't, a newer session has been introduced, and you
: could push the user to a "session timed out" page.

Isn't this a problem for multiple NAT or proxy users?

--
Roland Hall
/* This information is distributed in the hope that it will be useful, but
without any warranty; without even the implied warranty of merchantability
or fitness for a particular purpose. */
Technet Script Center - http://www.microsoft.com/technet/scriptcenter/
WSH 5.6 Documentation - http://msdn.microsoft.com/downloads/list/webdev.asp
MSDN Library - http://msdn.microsoft.com/library/default.asp