Monitoring concurrent users in ASP.NET v1.1 app

[Guest]

I have an ASP.NET application which my company sells comercially. We license
on a concurrent user model, but we currently rely on the "honor" system for
the customers to give us their best guess as to the maximum number of
concurrent users they will need. We do this because, so far, we have not
been able to come up with any mechanism for reliably monitoring how many
users have active sessions and locking out users until a license becomes
"free".

We've tried using the Session_Start and Session_End events, but these events
don't fire reliably and we end up not accuratley counting the active
sessions. We even had a Microsoft engineer trying for several days to help
us with this problem but he could not come up with a solution either.

Has anyone succesfully implemented a concurrent license model on an ASP.NET
application? The system has to "free" a license when the user just closes
IE, or when the session tmes out. If anyone has done this I would appreciate
being pointed in the right direction.

 

[Jim Cheshire]

I have an ASP.NET application which my company sells comercially. We
license on a concurrent user model, but we currently rely on the
"honor" system for the customers to give us their best guess as to
the maximum number of concurrent users they will need. We do this
because, so far, we have not been able to come up with any mechanism
for reliably monitoring how many users have active sessions and
locking out users until a license becomes "free".

We've tried using the Session_Start and Session_End events, but these
events don't fire reliably and we end up not accuratley counting the
active sessions. We even had a Microsoft engineer trying for several
days to help us with this problem but he could not come up with a
solution either.

This is not something that can be accomplished reliably. Session_End doesn't
fire deterministically. Therefore, in order to know for sure how many users
there are, you would need to have the users authenticate and maintain that
count yourself.

--
Jim Cheshire
================================
Blog: http://blogs.msdn.com/jamesche

Latest entry:
Getting the PID and TID of a COM Call

Describes how to get the PID of the
dllhost process a COM call is executing
in and how to locate the thread as well.

 

[Guest]

We've tried using the Session_Start and Session_End events, but these
events don't fire reliably and we end up not accuratley counting the
active sessions. We even had a Microsoft engineer trying for several
days to help us with this problem but he could not come up with a
solution either.

How about using Application_BeginRequest? You can use that event handler to
track each request. Perhaps query a table to see how many "active" users
there are?


Also, what sort of problems were you having with Session_Start/Session_End?
These only fire after a session has timed out (default is 20 minutes).

 

[Guest]

Thanks to Jim and Stan for the replies. I'll provide some more details.

We do authenticate users, so we can keep track when a user logs in. The
real problem is with keeping track of when the user stops using the
application. There can be several scenarios in which a user coudl "log out".
First, the user could use the log out functionality we provide, which they
rarely do. Second, most commonly, they simply close Internet Explorer. We
have been able to come up with some java script that captures the closing of
IE on the client and instantly aborts the session on the server immediately.
The third scenario would be that the browser sessions just times out.

Like Jim correctly states, the Session_End does not fire reliably, because
thsi would be the way to do this. If I'm not mistaken, the Application_Start
and Application_End events fire when the application starts for the first
time, not every time a user starts a session.

It really appears that keeping track of concurrent users in an ASP.NET
application is something that one can not do. I find this hard to believe.

Anyone else have any good ideas?

 

[Jim Cheshire]

Thanks to Jim and Stan for the replies. I'll provide some more
details.

We do authenticate users, so we can keep track when a user logs in.
The real problem is with keeping track of when the user stops using
the application. There can be several scenarios in which a user
coudl "log out". First, the user could use the log out functionality
we provide, which they rarely do. Second, most commonly, they simply
close Internet Explorer. We have been able to come up with some java
script that captures the closing of IE on the client and instantly
aborts the session on the server immediately. The third scenario
would be that the browser sessions just times out.

Bill,

The first thing you need to realize is that you're not going to be able to
do this as reliably as you'd like to. With that said, you could use a very
small sliding timeout, but you'll have to realize that you're going to have
inaccurate readings. If it were up to me, I'd take a different route. A web
application is just not conducive to this kind of architecture because of
its disconnected nature.

By the way, this is not a limitation of ASP.NET. It's simply the result of
the HTTP architecture.

--
Jim Cheshire
================================
Blog: http://blogs.msdn.com/jamesche

Latest entry:
Getting the PID and TID of a COM Call

Describes how to get the PID of the
dllhost process a COM call is executing
in and how to locate the thread as well.

 

[Guest]

Jim,

That is the conclusion I have been reluctantly coming to for several months
now. I was just hoping I was missing something.

 

[Darren Kopp]

Would it be possible to do something with ajax? Something like when
the user closes the window it calls a function that keeps track of the
users currently in the system. A couple articles to help you see what
i mean would be http://www.4guysfromrolla.com/webtech/100604-1.shtml
and http://ajax.schwarz-interactive.de/csharpsample/default.aspx.

I would think you would be able to do something like that, but then you
have a reliance on javascript being enabled as well.

HTH,
Darren Kopp
http://blog.secudocs.com/

 

[Guest]

Darren,

I will look into the ajax approach. Having javascript enabled is necessary
to run our application anyway, so that is not an issue. This is an Intranet
application, not a public internet site, so we can specify some requirements
for running the appliaction.