Viewer hangs after hour of non-use.

[lwesker]

We have a Linux Compute Farm at our company, using VNC to connect in from our Windows 7 desktop. The problem started when the Farm was reconfigured to use PXE boot from a common image (so its OS was reinstalled) instead of having separate OS installs on every machine. Previously I have been using UltraVNC to view the Farm, and all was very stable, for the last 10 years or so. This reconfigure also included partitioning the Farm on a unique VLAN and DNS domain, and who know what else IT has done.

I am currently able to connect and use the server from UltraVNC's viewer without problems. As long as I am interacting with the viewer, all works perfectly.

However if I walk away for about an hour or more, the viewer is always goes non-responsive, leaving a stuck window and no response. After a couple of seconds of trying to interact with the non-responsive viewer window, the viewer eventually pops up a connection lost window, whereby I am able to close down the viewer. On the next connect, all is working again until I leave it idle for an hour or more. It is quite aggravating.

The server side is the RHEL v5 standard default install, although for the purpose of this problem I also tried a different server and also different viewers. This problem seems to be specific to the UltraVNC viewer. The only other people in the company I talked to who are also experiencing this problem are using UltraVNC. As I prefer UltraVNC I would like to get this resolved.

Is this a bug in the viewer since it does not immediately pop up a error window instead of hanging up? Any idea of what kind of network background traffic or timeout event could be triggering this behavior?

[lwesker]

The problem still exists. Kind of got use to the hassle. Looking again for a solution or way to help debug.

Since the original post, I verified it is definitely inside UltraVNC's vncviewer, having tired other server and viewer combinations.

Also notice that while the viewer window is displayed it does not crash, but when minimized to the toolbar for a period of time (roughly one hour), the viewer is hung when I click to open back up, and after some short timeout the connection closed dialog box displays.

As I mentioned before, I had been using UltraVNC viewer for over a decade without issues, but the problem started when the company IT segmented the network using VLAN and stuff. The viewer and server are now on different subnets.

It acts as if some network timeout is breaking the connection in someway, or sending the viewer some kind of keepalive message, that the viewer does not understand as valid RFB protocol and crashes.

Is there some kind of diagnostic dump I can enable within the viewer? Something please! Just too irritating to have to close/restart the viewer every time I park the viewer for a period of time.

[Rudi De Vos]

A minimized viewer behave different

+ File transfer get priority
+ It doesn't ask for updates as he try to avoid unneeded updated on a invisable screen.

SO it's indeed possible that no data is send for several minutes...

Nat router can close ports on inactivity, but routers normal doesn't.

[lwesker]

In this case, not going through a router or NAT, just switches.

But how do we I capture that a port closing by a switch is doing this? Some debug trace file option in the viewer? Then how to stop the port closings from occurring or crashing the viewer when it happens? Since other people here using viewers from different companies do not exhibit the hang problem I have no ammo to go back to IT to tell them to change their architecture. Something is unique with UltraVNC viewer. IT will just come back and say use a different viewer, which I would rather not do because of some of its features when talking to UltraVNC servers on other machines.

I noticed an undocumented command line switch "/socketkeepalivetimeout n", but release notes imply it is for SC only. But will it do something for me here? Documentation does not specify the "n" value. Is it seconds, minutes? Is default 0 for disabled?

[Rudi De Vos]

I don't think this will change the behaviour.
A minized viewer use other internals...to minize data transfer.

Added to the to check list...as only a source change can make the behaviour change.
But a hell to debug and we are not even shore it's a viewer issue, It could be that the server timeout after x minutes of inactivity...

[lwesker]

I had tried the UltraVNC viewer with several different servers on the Linux machine and other viewers with the default CentOS server on the Linux. In all combinations I tried, it was only with the UltraVNC viewer that hang. Most people I work with are using RealVNC viewer to the same servers I connect to, with no issues.

This problem began when IT reconfigured the LAN between the client (on Windows) and the server (on Linux). I had been using the UltraVNC and Linux server for well over a decade (almost since UltraVNC first version release) before the reconfigure, with no problems.

So it really is something the network is triggering that is causing your viewer the problems.

If the viewer itself does not have a diagnostic logging mode, perhaps you know of some network traffic monitor I could install on my PC that can observe everything the viewer sends or receives, to determine the last thing that happens.

I can understand debugging this can be very difficult and am willing to run whatever I can here to give you useful info.

[Rudi De Vos]

quick test
http://www.uvnc.eu/download/1203/vncvie ... zetest.zip

minimize put the viewer in dormant state.
A dormant state don't ask new update request, instead of none we now ignore 2/3.
Domant state is also used by FileTransfer... possible this goona crash or make it slower.

bin 32bit Vista>= compiled

[lwesker]

Thanks Rudi for the test version. As I understand the change made, it would continue to make a reduced number of update requests in the background while in the minimized dormant state.

Unfortunately it did not fix the problem. The test version did the same hang after inactivity.

But I did notice a difference in behavior related to this problem. I had been using v1.0.9.6.1 viewer. After seeing the change, I tried the most recent official v1.2.0.3 and observe it also has the changed behavior. So the tweak made for the test did not really affect the problem.

What is different on either v1.2.0.3 version (and for the better) is that after the hour or so of dormant state and I expand the viewer, it is still hung up. After a few seconds, as before, the "server closed connection" popup occurs. But now when I hit the close button in it, the viewer does not actually close. Instead the connection is reestablished and I am able to continue with the viewer and not have to log in again.

An incidental thing I noticed is that the official v1.2.0.3, when it restored the viewer after hang, the view window had a lot of corruption and I had to reduce from full screen and go back to clean up.

But the test version does not do the corruption when connection restored, so must have some other bug fixes in it not yet released.