Client Hangs and how to track them

I dont know if I'm unusual, but I get very few actual crashes from SL running on Vista. What I get a lot of though is the client hanging up, obviously having lost communications with the host server. Unless I am actually moving at the time, it can take a while to notice this nhas happened. Chat dries up, music continues, and I eventually see that I'm getting no network traffic.

I get this on multiple machines of different makes. By contrast EVE-Online never seems to have this problem, or very very rarely, and then it tells me pretty quickly.

The problem is annoying, but there also seems to be no Linden monitoring of it. Unlike a true crash, the Crash Logger does not fire up. I have to close the client and restart it, which usually works OK.

I think Linden should put some efforts into metering this type of error, and protecting against it. The client (and the current server) should be able to tell that it's comms have broken, and the user informed of the problem. If that can't be done, there should be a UI command to "report hung state and restart". Ideally, the client should be able to restart the lower-layers of the protocol stack without having to restart the whole session.

I can think of a number of possible causes for this, from simple packet latency to the ISP changing the client IP address without warning, or a problem in the home router NAT. But its hard to see how Linden will fix the problem if they dont meter and analyse it.

Or is it just me???

as i just said in a nother thread, i see this all the time, and in my case it's mostly my ISP's fault. but i wouldn't say that the client has hung because it's still running fine, it just cann't talk to the sim which is needed to do almost anything.

Whether we say the client is hung or not doesn't really matter. The service is certainly hung as seen on the client.

Indeed I suspect that ISPs are part of the cause, but SL seems far more vulnerable to such fadeouts than other online games. I run EVE-Online on the same machines and rarely have a problem.

So I think this is something that COULD be addressed by using a more robust protocol stack. But I'm not exactly asking for such a fix right now, just some evidence that they are aware of and investigating the issue.