Last post Aug 21, 2008 11:07 PM by shlomybsh
Jun 20, 2006 04:24 PM|LudovicoVan|LINK
Since i never see this answered, and there just seem to be discussions on what's onunload and what can't be done, i thought this was a good candidate for a FAQ.
Q: How to reliably trap a web client disconnect?
A: Happily, there is a reliable way to trap a client disconnect in (quasi) real-time. I believe it is not usually worth the case, so mind your approach first. Anyways, here it is:
The basic idea is have a very low timeout for the session (say N secs), and the client browser connect at intervals to the server (say each N/2 secs) to tell it: "i'm still here...". That is,
a basic keep-alive logic.
loading an image at intervals from a session-enabled http handler, etc. etc.
This way, when the user closes the browser, the session times out after at most N secs. (N could be something from 20 to 120 secs...) Actually, since in aspnet the session timeout is defined in minutes, you might think of a server-side timer to get a finer
HTH and feel free to ask, comment, or add...
Aug 30, 2006 09:01 AM|dotnetCarpenter|LINK
One could use the fact that the onunload event is fired every time the user leaves the page. The user might do so for tree reasons:
Because he or she
If the event is fired because of the last two reasons we want to take "logoff" actions (like saving objects, remove user from memory and so forth) but not if the reason is the first. Now a days AJAX is getting to be a reliable technique and has less overhead
compared to self-refreshing iframes (albeit there is another old school way - I'll get back to that later), so it make sense to use AJAX as a client caller. When the
unonload event is fired an AJAX call (alright you can use a normal HTTP call) with the user id is made to the server. You could use
Session.SessionID as a user id. On all of your pages you have an onload event that is fired when the user loads the page. Use that to make a another call (again you can use the
Session.SessionID) to the server to tell it that the user is still alive. If no such call is made to the server after N seconds you can assume that the user is gone.
The old school way
Instead of using AJAX and onload you could use an image on all of your pages (this image does not have to exist) with the user id as a parameter.
<img src="UserConnectionLogic.aspx?UserID=alznlv24bq1dgv452c1c5eir" />
The UserConnectionLogic.aspx is of course the page that handles "logoff" logic.
In both scenarios you can use the System.Threading.Timer Class.
- Jon E. Ronnenberg
Aug 30, 2006 02:12 PM|LudovicoVan|LINK
[quote user="dotnetCarpenter"]One could use the fact that the onunload event is fired every time the user leaves the page.
Sorry, but that's exactly what is NOT reliable, and the very reason why i wrote this contribution is that the Internet is flooded by that approach and misconception.
To understand what i mean, simply consider this: What if your younger brother inadvertently hits the big switch? Or your router crashes? Or a provider goes down? Or anything similar along the chain to the server fails?
This topic was meant to dissolve confusion, and give a RELIABLE way for the server to know that the client has disconnected.
This can be done with a keep-alive mechanism only.
Hope this clarifies. -LV
Aug 21, 2008 11:07 PM|shlomybsh|LINK
You Have a Nice Idea Here.
I use the Keep-Alive With Timer of Ajax in the Master Page. (I See that the Session End Before the time that i put in session TimeOut)
and its work !!!
The Problem is that I getting the Error Again ... :-(
The client disconnected