By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,497 Members | 1,287 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,497 IT Pros & Developers. It's quick & easy.

Monitoring concurrent users in ASP.NET v1.1 app

P: n/a
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.
--
Thanks,

Bill Manring

Dec 31 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Bill Manring wrote:
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.

Dec 31 '05 #2

P: n/a
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?
--
Thanks,

Bill Manring
"Bill Manring" wrote:
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.
--
Thanks,

Bill Manring

Jan 1 '06 #3

P: n/a
Bill Manring wrote:
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.

Jan 1 '06 #4

P: n/a
Jim,

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

--
Thanks,

Bill Manring
"Bill Manring" wrote:
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?
--
Thanks,

Bill Manring
"Bill Manring" wrote:
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.
--
Thanks,

Bill Manring

Jan 1 '06 #5

P: n/a
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/c...e/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/

Jan 1 '06 #6

P: n/a
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.

--
Thanks,

Bill Manring
"Darren Kopp" wrote:
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/c...e/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/

Jan 1 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.