Will UltraVNC attempt to Reconnect to the Repeater

[Rat]

Here's a scenario that I would like some clarification on...

If I install ChunkVNC as a service and it loses its connection to the repeater, (in my case because I killed the Perl repeater script and restarted it), will the ChunkVNC service attempt to reconnect to the Repeater?

As far as I can tell it doesn't, which is a problem when I have a couple of dozen of my customer's machines running the ChunkVNC service.

I've scrutinised the "ultravnc.ini" configuration file for a setting that might be used, but all I could find is "KeepAliveInterval" which I've already set to 5 without any effect.

Anyone know how to make UltraVNC reconnect to the repeater if the connection is dropped?

The UltraVNC manual says:

-autoreconnect
Is used in conjunction with the -connect switch when having a server "back-connect" to a listening viewer. You can use it in a batch file for your clients that are behind a firewall that is not under your control. The batch file looks something like this:
"c:\program files\ultravnc\winvnc" -autoreconnect -connect 12.34.56.78
On the local computer run the viewer in "listening" mode, and have someone on the server end run the batch file. The -autoreconnect will make the server end attempt to reconnect to the listening viewer if the connection drops or is closed. It will immediately reconnect to the listening viewer if the session is closed. Close the listening viewer altogether in order to stop the server end from "autoreconnecting" to your computer. The server attempts to "autoreconnect" for only a few seconds.
Note that this "autoreconnect" param must be before the "connect" one on the command line!

This seems to indicate that the service won't attempt to reconnect if the repeater is down for more than a few seconds. What we need is a more robust form of auto-reconnection which will keep trying for longer, even if the viewer is closed.

In my testing closing the viewer for a minute or two and then reconnecting always works, but killing and restarting the Repeater always permanently breaks the connection. If I then stop and restart the server the viewer can reconnect.

[redge]

this what I already tell, winvnc must continuous try autoreconnect until human disconnect.
but what happen if winvnc crunshed, maybe retry like you tell and YY too retry counter ?

edit:
the counter is only 30 seconds,
then it break and reconnect if remote reachable
otherwise it stop autoreconnect and never retry reconnect.

[Rat]

Well if Rudi or someone can confirm that this is the designed behaviour of UltraVNC and that there is no configuration option to prevent it, then I can write a little Windows service which monitors the Repeater and restarts the UltraVNC service if the Repeater dies and then comes back.

[JonD]

Rat,
Sound like a nice solution. I would like to be able to set the time interval though. If the repeater was off for several hours, I wouldn't want the client generating an excessive number of "tries" to connect.

Ideally, it would start with frequent "tries" and then only try every (say) 10 minutes?

Perhaps 2 settings
- one for short term
- one for longer term

JonD

[supercoe]

Interesting as I run the Windows repeater and have closed and reopened it many times with the service installed.

Sometimes I'll do it just to be reminded which ID's are connecting.

[lall]

As much as i know, if you kill repeater and re-start it, the server connects back to it in about 7 min. Atleast, that's what my log files show me.

[JonD]

I don't usually leave the service installed on a client... however, whenever I have, I'm disconnected the next day.

My repeater shuts down over night and restarts every morning. It usually ends up with a new public IP address so maybe that's related in some way. (I use NO-IP to handle the dynamic IP).

JonD

[supercoe]

JonD,

The changing IP is the problem, I've had trouble with this before.

It seems that UltraVNC only resolves the DNS name once when the server is started. If we can confirm this I'll ask Rudi for a patch.

[JonD]

I was wondering if that might be the issue. I need to force the change in IP address to solve the issue that I previously documented with respect to CheckPoint routers.

JonD

[Rat]

All my testing was with the Perl repeater on a fixed IP address... The behaviour is consistent... If I kill the repeater and then restart it, the UltraVNC server never re-establishes a connection.

[JonD]

I'm using a different repeater... but the results are the same.

JonD

[supercoe]

I'm not able to replicate this issue.

ChunkVNC 3.2 unmodified download.

Using a CentOS based Linux VPS with a DNS address pointing to it.

1) I start InstantSupport and it connects fine.
2) I ctrl+c the repeater to kill it.
3) After a couple minutes I start the repeater again.
4) About 20 seconds later the UltraVNC server connects.

I've tried it running normally and installing as a service.

Normal run:
[syntax="perl"][root@server1 ~]#perl ultravnc_repeater.pl 5901 5500
perl module IO::Socket::INET6 not available: no IPv6 support.
Fri Jan 7 19:04:54 2011: ultravnc_repeater: starting up. pid: 9477
Fri Jan 7 19:04:54 2011: watching for IPv4 connections on 5901/client.
Fri Jan 7 19:04:54 2011: watching for IPv4 connections on 5500/server.
Fri Jan 7 19:06:05 2011: new vnc server connecting.
Fri Jan 7 19:06:05 2011: storing new vnc server with ID:425083.
[root@server1 ~]#perl ultravnc_repeater.pl 5901 5500
perl module IO::Socket::INET6 not available: no IPv6 support.
Fri Jan 7 19:08:03 2011: ultravnc_repeater: starting up. pid: 9479
Fri Jan 7 19:08:03 2011: watching for IPv4 connections on 5901/client.
Fri Jan 7 19:08:03 2011: watching for IPv4 connections on 5500/server.
Fri Jan 7 19:08:23 2011: new vnc server connecting.
Fri Jan 7 19:08:23 2011: storing new vnc server with ID:425083.
[/syntax]

Normal run + installing as service:
[syntax="perl"][root@server1 ~]#perl ultravnc_repeater.pl 5901 5500
perl module IO::Socket::INET6 not available: no IPv6 support.
Fri Jan 7 19:16:49 2011: ultravnc_repeater: starting up. pid: 9481
Fri Jan 7 19:16:49 2011: watching for IPv4 connections on 5901/client.
Fri Jan 7 19:16:49 2011: watching for IPv4 connections on 5500/server.
Fri Jan 7 19:17:00 2011: new vnc server connecting.
Fri Jan 7 19:17:00 2011: storing new vnc server with ID:675690.
Fri Jan 7 19:17:15 2011: new vnc server connecting.
Fri Jan 7 19:17:15 2011: closing and deleting previous vnc server with ID:675690.
Fri Jan 7 19:17:15 2011: storing new vnc server with ID:675690.
[root@server1 ~]#perl ultravnc_repeater.pl 5901 5500
perl module IO::Socket::INET6 not available: no IPv6 support.
Fri Jan 7 19:19:27 2011: ultravnc_repeater: starting up. pid: 9483
Fri Jan 7 19:19:27 2011: watching for IPv4 connections on 5901/client.
Fri Jan 7 19:19:27 2011: watching for IPv4 connections on 5500/server.
Fri Jan 7 19:19:52 2011: new vnc server connecting.
Fri Jan 7 19:19:52 2011: storing new vnc server with ID:675690.
[/syntax]

redge: replaced code by syntax=perl

[JonD]

What happens if the repeater is down for longer periods of time as opposed to a relatively quick restart?

BTW I've managed to lock myself out for another reason by switching the client to a static LAN IP address... I thought I might get away with that! One more thing !not! to do.

JonD

[supercoe]

JonD,

In the past with the windows repeater I've left it off overnight and have had similar results. I could test this if needed but I'm already having different results.

I'll test the changing of a local IP.

[redge]

What happens if the repeater is down for longer periods of time as opposed to a relatively quick restart?

if you meaning: if ip/FQDN responding, it just retry to reconnect
if you meaning: if ip/FQDN not responding ?
in this case, winvnc stop retry and close
i did not success winvnc trying to reconnect after 7min like someone wrote

[Rat]

I just did a test waiting 24hrs with the Perl repeater and the server never re-connected....

[supercoe]

I'll test again waiting longer.

[Mimamau]

I have the same problems. When the server is connected to the repeater and you pull the network connection, winvnc will display a dialog box "Initiate Connection". If you then restore the network connection, nothing happens. Only if you close the dialog box, winvnc reconnects to the repeater.

This is a big problem for me as I have a lot of boxes on unreliable 3G and other wireless connections.

I tried to make the chunkvnc service to close the box on itself (in this "If WinExists( "Initiate Connection" ) Then..." part, but it doesen't work.
EDIT: Ok, just noticed, chunkvnc doesnt' have a service so this won't work.

Will now take a look at the winvnc code if its possible to silently drop this dialog box.

[redge]

Rudi fixed a bug of Reconnect of vncviewer, don't know this trouble winvnc or both
but we not yet the public update 1.0.5.1?

[Mimamau]

With winvnc.exe version 1.0.5.2 it doesn't seem to happen.