slow response to connect request

[gneuner]

Hi,

I use UVNC to administer several machines. Since upgrading to 1.4.0.6 (from 1.3.8.1), I suddenly have one LOCAL server that takes a significantly long time to respond to a connect request. Once the connection is established it works fine.

The problem server and viewer both are on wired network in the same building. This server reliably takes 10..20 seconds to respond to a connect request. Following reboots the time to respond varies widely - sometimes taking up to several minutes. This machine does NOT sleep, does not power down ethernet port, has plenty of RAM and its drive is SSD (so no spin-up of idle disks, etc.).

For comparison, other servers on the same network respond immediately. Two remote servers that are connected to via Internet respond in just a couple of seconds [allowing for latency, it seems they also are responding immediately].

All of the machines are running Win10 21H2, are up to date with patches, and all have the same configuration for antivirus and firewall. The UVNC service is configured to start automatically at boot (and normally it would be active even before the login screen appears). I glanced at the log on the problem server: nothing jumped out, but the log is not recording debug information. There were no errors from the service in the Windows logs.

I can't find any obvious reason for the delay in responding to connect requests. Has anyone else seen this behavior? Anything in particular I might look for?

Thanks,
George

Also: I don't seem to receive notifications when people post. I will check in periodically, but if you ask me a question, please don't be offended if I don't answer quickly.

[Rudi De Vos]

In the log we translated the ip by the dns name, but is seems to take upto 20 seconds to get the dns answer.
This is removed in the later versions ( current you can download 1.4.0.10 via the forum)

[SkyBeam]

In addition you might want to check your DNS configuration. You were referring to a server machine. Those should usually not only have a forward-DNS but also a reverse-DNS entry.
Even DHCP clients can have an automatic reverse-DNS (PTR) entry in corporate environments. If the configured DNS server is responding immediately with a PRT entry there will be no noticeable connect delay. The delay only happens if the DNS request cannot be answered and times out. So even if the change was reverted you might want to check your DNS configuration.

[gneuner]

Hi,

In addition you might want to check your DNS configuration. You were referring to a server machine. Those should usually not only have a forward-DNS but also a reverse-DNS entry.

I was referring to the UVNC server/service to distinguish from the viewer client. These machines all are workstations - not "server" OS editions.

Even DHCP clients can have an automatic reverse-DNS (PTR) entry in corporate environments. If the configured DNS server is responding immediately with a PRT entry there will be no noticeable connect delay. The delay only happens if the DNS request cannot be answered and times out. So even if the change was reverted you might want to check your DNS configuration.

I will check the DNS setup, but I think it is unlikely to be the problem - the machine that is slow to answer connect requests is on the same local network as the viewer machine. There are several other local machines that answer immediately. All have static IPs on the local network.

[gneuner]

In the log we translated the ip by the dns name, but is seems to take upto 20 seconds to get the dns answer.
This is removed in the later versions ( current you can download 1.4.0.10 via the forum)

Thanks, I will give a newer version a try.

[Neustradamus]

@gneuner: Have you tried with UltraVNC 1.4.2.0?
It has been solved?

[gneuner]

@gneuner: Have you tried with UltraVNC 1.4.2.0?
It has been solved?

Hi,

I tried 1.4.0.9 which was the latest release at the time (1.4.0.10 was still on the developer channel).

It did solve the slow connect but created another problem on a different machine: occasionally it refuses to connect until the machine is rebooted (stopping/restarting the service won't fix it). I had this same problem on multiple machines with 1.3.9.1 and I am not thrilled at seeing it again.

I will try 1.4.2.0 now that it is out. Fingers crossed.
Thanks,
George

[Ludovic]

@gneuner: With 1.4.3.6, it is solved?

[gneuner]

@gneuner: With 1.4.3.6, it is solved?

So far no problems, but I've been on 1.4.3.6 for only a couple weeks.
Fingers crossed.