How determine that the visitor is leave

[Alexander Vasilevsky]

How do you determine (on the client, on the server) that the visitor leave
the site?

http://www.alvas.net - Audio tools for C# and VB.Net developers

 

[Mark Rae [MVP]]

How do you determine (on the client, on the server) that the visitor leave
the site?

There is no reliable way to do this due to the disconnected architecture of
the web...

A client sends a request to a server.
The server processes the request and sends a response back to the client.
The server has no knowledge of what happens after that until / unless it
receives another request from the same client.

There are suggested options using the onunload / onbeforeunload JavaScript
events, but they cannot be guaranteed to work either...

My advice would be don't even bother...

 

[David Thielen]

You have to use the timeout event - there is no event when the client goes to
another site - so all you can do is say 10 minutes has passed, they must have
left.

--
thanks - dave
david_at_windward_dot_net
http://www.windwardreports.com

Cubicle Wars - http://www.windwardreports.com/film.htm

 

[Mark Rae [MVP]]

You have to use the timeout event - there is no event when the client goes
to
another site - so all you can do is say 10 minutes has passed, they must
have
left.

There is no timeout event - sessions have a Timeout property after which the
Session_End event fires, but only if the site is using inproc sessions...

 

[Peter Bromberg [C# MVP]]

I've tried things like calling to them ( "Vistor? Are you still there?") but
that doesn't seem to work either.

Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
MetaFinder: http://www.blogmetafinder.com

 

[Juan T. Llibre]

You could have some fun and use "IsClientConnected" :

http://msdn2.microsoft.com/en-us/library/system.web.httpresponse.isclientconnected.aspx

There's one thing I've never been able to figure out about IsClientConnected.
Isn't *being connected* a pre-requisite to it being used ?

 

[Patrice]

AFAIK. it just allows to see if the destination of the current HTTP response
is still connected. For example if a user triggers a long running page and
closes its browser (or just goes on another page on the same site), my
understanding is that IsClientConnected will be false as the network link
between the server sending the response and the "destination" of this
response is broken.

It just allows to see if the response that is currently sent has a receiver
on the other side of the network link

 

[Juan T. Llibre]

re:
!> AFAIK. it just allows to see if the destination of the current HTTP response is still connected

I'm well aware of that.

I'll also bet that 99.9999% of all clients are still connected when IsClientConnected is used.
After all, IsClientConnected is checked only in response to a client request for a page.

Most page processing, btw, takes very little time.

A client would have to have very nimble fingers to close the browser
or move to another page before his latest request is fulfilled.

The intended purpose, of course, is to save server resources by not continuing
to process a request which will have no destination, but it seems to me that
IsClientConnected takes up a lot of server resources by itself.

 

[Patrice]

Wanted to mention this to point out that this is unlikely to solve the OP
problem... IMO the OP best bet would be to explain what he wants to do i.e.
why he needs to track down leaving visitors.

For example in most cases, it's likely the current user count seen on some
site is just an approximation. If this is for cleanup, cleanup could likely
be done another way etc.. etc...