Update: UltraVNC 1.4.3.6 and UltraVNC SC 1.4.3.6: https://forum.uvnc.com/viewtopic.php?t=37885
Important: Please update to latest version before to create a reply, a topic or an issue: https://forum.uvnc.com/viewtopic.php?t=37864
Join us on social networks and share our announcements:
- Website: https://uvnc.com/
- GitHub: https://github.com/ultravnc
- Mastodon: https://mastodon.social/@ultravnc
- Facebook: https://www.facebook.com/ultravnc1
- X/Twitter: https://x.com/ultravnc1
- Reddit community: https://www.reddit.com/r/ultravnc
- OpenHub: https://openhub.net/p/ultravnc
Important: Please update to latest version before to create a reply, a topic or an issue: https://forum.uvnc.com/viewtopic.php?t=37864
Join us on social networks and share our announcements:
- Website: https://uvnc.com/
- GitHub: https://github.com/ultravnc
- Mastodon: https://mastodon.social/@ultravnc
- Facebook: https://www.facebook.com/ultravnc1
- X/Twitter: https://x.com/ultravnc1
- Reddit community: https://www.reddit.com/r/ultravnc
- OpenHub: https://openhub.net/p/ultravnc
Repeater/autoreconn - How to always-on reverse connection?
Repeater/autoreconn - How to always-on reverse connection?
Hello Rudi,
is it possible to have an always-on reverse connection to repeater?
Searching the forum I only found this:
https://forum.ultravnc.net/viewtopic.php?t=30669
The repeater kills all *not* established connections frequently. But this wouldn't be a problem, they'd reconnect. But what if the repeater would be inaccessible for more then 5-10 minutes because of a server or internet take-out?
How to force wincnc.exe to retry reconnection endlessly?
is it possible to have an always-on reverse connection to repeater?
Searching the forum I only found this:
https://forum.ultravnc.net/viewtopic.php?t=30669
The repeater kills all *not* established connections frequently. But this wouldn't be a problem, they'd reconnect. But what if the repeater would be inaccessible for more then 5-10 minutes because of a server or internet take-out?
How to force wincnc.exe to retry reconnection endlessly?
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
Re: Repeater/autoreconn - How to always-on reverse connectio
Current repeater has a keep_alive message between repeater and server.
This was added to prevent timeouts.
This was added almost a year ago.
The only problem is that old servers don't understand the timeout message and close on unknown message.
With autoreconnect on the old server keeps reconnecting
With autoreconnect the new server should only connect once and keep the socket open by the keep alive.
This was added to prevent timeouts.
This was added almost a year ago.
The only problem is that old servers don't understand the timeout message and close on unknown message.
With autoreconnect on the old server keeps reconnecting
With autoreconnect the new server should only connect once and keep the socket open by the keep alive.
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
Re: Repeater/autoreconn - How to always-on reverse connectio
Current repeater has a keep_alive message between repeater and server.
This was added to prevent timeouts.
This was added almost a year ago.
The only problem is that old servers don't understand the timeout message and close on unknown message.
With autoreconnect on the old server keeps reconnecting
With autoreconnect the new server should only connect once and keep the socket open by the keep alive.
This was added to prevent timeouts.
This was added almost a year ago.
The only problem is that old servers don't understand the timeout message and close on unknown message.
With autoreconnect on the old server keeps reconnecting
With autoreconnect the new server should only connect once and keep the socket open by the keep alive.
Re: Repeater/autoreconn - How to always-on reverse connectio
THX for answer. But...
Yes, I knew this already. And/Or I thought to have understood this. But this influences only the behaviour of repeater and server while a connection can be physically made.
The question was, how to have winvnc.exe reconnect after the server, which is hosting the repeater (!), was down for 2 hours? Or internet connection was down for a longer time.
It's not clear for me how keep alives should help in this situations ?!?! What does the new winvnc.exe do in these situations? Where are the differences to the old winvnc.exe?
Yes, I knew this already. And/Or I thought to have understood this. But this influences only the behaviour of repeater and server while a connection can be physically made.
The question was, how to have winvnc.exe reconnect after the server, which is hosting the repeater (!), was down for 2 hours? Or internet connection was down for a longer time.
It's not clear for me how keep alives should help in this situations ?!?! What does the new winvnc.exe do in these situations? Where are the differences to the old winvnc.exe?
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
Re: Repeater/autoreconn - How to always-on reverse connectio
If no connection can't be made, then it's a pure server behaviour, independed of the repeater.
If the repeater has keepalive or not wil not make a difference.
When i remember correct, a server keeps trying to connect.... after he get's a timeout for the outgoing connection,
he just try again.
If the repeater has keepalive or not wil not make a difference.
When i remember correct, a server keeps trying to connect.... after he get's a timeout for the outgoing connection,
he just try again.
Re: Repeater/autoreconn - How to always-on reverse connectio
Hi Rudi,
as far as I can remember, ages ago, I read something about an autoreconnect timespan of 5 minutes until a connection to repeater or viewer has to be established until the server gives up trying.
But, possibly also ages ago, I misunderstood something completely or I mixed something up in the meantime.
So, would you please have a look at the code, when you have a little time? To be absolutely 100% sure.
as far as I can remember, ages ago, I read something about an autoreconnect timespan of 5 minutes until a connection to repeater or viewer has to be established until the server gives up trying.
But, possibly also ages ago, I misunderstood something completely or I mixed something up in the meantime.
So, would you please have a look at the code, when you have a little time? To be absolutely 100% sure.
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
Re: Repeater/autoreconn - How to always-on reverse connectio
The time is the default tcp connect() timeout value ( OS depended ), this is very long.
Re: Repeater/autoreconn - How to always-on reverse connectio
THX Rudi.
We observe customers having initially established a connection to our repeater, shown as "waiting servers". But here and there single servers disappear from repeater and they do not come back. If we call them by phone they confirm the vnc service is up and running. Internet is working, at least at the moment.
Ok, based on your explanation I would interpret the observed as follows:
1. The customers where disconnected because e.g. an internet problem on customers side.
2. Winvnc.exe immediately retries to reconnect to repeater, but is not able to.
3. Because of the TCP timeout winvnc.exe waits X minutes before retry.
4. If the internet connection is back in the meantime, we have to wait until the timeout runs down. Then the customer will reappear at repeater.
Correct? This means, if I wait long enough, every customer should reappear again. Right?
We observe customers having initially established a connection to our repeater, shown as "waiting servers". But here and there single servers disappear from repeater and they do not come back. If we call them by phone they confirm the vnc service is up and running. Internet is working, at least at the moment.
Ok, based on your explanation I would interpret the observed as follows:
1. The customers where disconnected because e.g. an internet problem on customers side.
2. Winvnc.exe immediately retries to reconnect to repeater, but is not able to.
3. Because of the TCP timeout winvnc.exe waits X minutes before retry.
4. If the internet connection is back in the meantime, we have to wait until the timeout runs down. Then the customer will reappear at repeater.
Correct? This means, if I wait long enough, every customer should reappear again. Right?
Re: Repeater/autoreconn - How to always-on reverse connectio
OK, I dug deeper.
From sever_access.txt:
As you can see, every 11 minutes winvnc.exe has to connect again. Before that hapens, it has been completely disappeared from repeater for 3 1/2 minutes.
This means 7 1/2 minutes visible on repeater, 3 1/2 minute not visible on repeater.
How to explain that? Even if the 'old' repeater kicks not negotiated connections frequently, I'd expect winvnc.exe to come back immediately, not after 3 1/2 minutes. Or is this exactly the TCP timeout period?
From sever_access.txt:
Code: Select all
29.09.2015 12:17;2123456;XXX.216.110.YYY
29.09.2015 12:29;2123456;XXX.216.110.YYY
29.09.2015 12:40;2123456;XXX.216.110.YYY
29.09.2015 12:51;2123456;XXX.216.110.YYY
29.09.2015 13:02;2123456;XXX.216.110.YYY
29.09.2015 13:13;2123456;XXX.216.110.YYY
29.09.2015 13:24;2123456;XXX.216.110.YYY
29.09.2015 13:35;2123456;XXX.216.110.YYY
29.09.2015 13:46;2123456;XXX.216.110.YYY
29.09.2015 13:57;2123456;XXX.216.110.YYY
29.09.2015 14:09;2123456;XXX.216.110.YYY
29.09.2015 14:20;2123456;XXX.216.110.YYY
29.09.2015 14:31;2123456;XXX.216.110.YYY
29.09.2015 14:42;2123456;XXX.216.110.YYY
29.09.2015 14:53;2123456;XXX.216.110.YYY
29.09.2015 15:04;2123456;XXX.216.110.YYY
This means 7 1/2 minutes visible on repeater, 3 1/2 minute not visible on repeater.
How to explain that? Even if the 'old' repeater kicks not negotiated connections frequently, I'd expect winvnc.exe to come back immediately, not after 3 1/2 minutes. Or is this exactly the TCP timeout period?
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
Re: Repeater/autoreconn - How to always-on reverse connectio
Info:
When you make a tcp connection server<->repeater
old
server ->connect repeater
repeater wait viewer ( forever )
server wait repeater ( until a router close the port, inactive)
repeater send viewer data to server
new
server ->connect repeater
repeater wait viewer ( forever)
repeater send keepalive message, server answer i'm online
or repeater send the viewer data
If server close, a end socket message is send and tcp connection is broken
if repeater close , a end socket message is send and tcp connection is broken
if some part of the network path is broken
*old repeater
keep waiting, no end socket message arrive
There is some cleanup routine that kill all connections X mintues to prevent ghost connections
*new repeater
fail to send keepalive, socket broken
The cleanup routine is reset on ach keepalive message
*server
He doesn't know the socket is broken, and keeps waiting until some timeout close everything.
When you make a tcp connection server<->repeater
old
server ->connect repeater
repeater wait viewer ( forever )
server wait repeater ( until a router close the port, inactive)
repeater send viewer data to server
new
server ->connect repeater
repeater wait viewer ( forever)
repeater send keepalive message, server answer i'm online
or repeater send the viewer data
If server close, a end socket message is send and tcp connection is broken
if repeater close , a end socket message is send and tcp connection is broken
if some part of the network path is broken
*old repeater
keep waiting, no end socket message arrive
There is some cleanup routine that kill all connections X mintues to prevent ghost connections
*new repeater
fail to send keepalive, socket broken
The cleanup routine is reset on ach keepalive message
*server
He doesn't know the socket is broken, and keeps waiting until some timeout close everything.
Re: Repeater/autoreconn - How to always-on reverse connectio
Ok, tested with local LAN connection, no firewalls, not even a Windows firewall, NATs etc. in between.
Sorry if I insist, but we need this behaviour to be fixed or at least fully understood. To set/configure the connection timeout within winvnc.exe to 1 minute or less instead of using system default would be a solution we could live with.
FYI: Possibly we're talking about something a new repeater with a new server would never have. But we are forced to use our repeater with old and new servers. So, I do the test with new server against old repeater.
Yes, seems to be the repeater is kicking the connection. This was clear. But does the cleanup routine also send a end socket message? Seems not, or winvnc.exe doesn't recognize it. Because winvnc.exe disappears for 3-4 minutes, and comes then back again. Seems to have a timeout.Rudi De Vos wrote: if repeater close , a end socket message is send and tcp connection is broken
...
There is some cleanup routine that kill all connections X mintues to prevent ghost connections
Yes, exactly this seems to happen. But why? This is main the question. Should winvnc.exe be notified with a end socket message, shouldn't it? From my knowledge and your explanation not explainable. Or do I still miss something?Rudi De Vos wrote: He doesn't know the socket is broken, and keeps waiting until some timeout close everything.
Sorry if I insist, but we need this behaviour to be fixed or at least fully understood. To set/configure the connection timeout within winvnc.exe to 1 minute or less instead of using system default would be a solution we could live with.
FYI: Possibly we're talking about something a new repeater with a new server would never have. But we are forced to use our repeater with old and new servers. So, I do the test with new server against old repeater.
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
Re: Repeater/autoreconn - How to always-on reverse connectio
close message is part of the tcp protocol, not vnc.
Found the server issue, but there is no parameter to change.
When a server loose his connection he try to reconnect, to avoid flooding there is an increasing timeout.
On each connection failure, the counter is increased by 10 sec, until his max of 30minutes
When a connection is made, the counter is reset
Using a repeater, the connection is broken by the repeater, so the timer increase.
The problem is that the reset is done when a viewer connect...
So you see, after a while disconnecting the repeater make the server wait 30minutes before he reconnect again.
Found the server issue, but there is no parameter to change.
When a server loose his connection he try to reconnect, to avoid flooding there is an increasing timeout.
On each connection failure, the counter is increased by 10 sec, until his max of 30minutes
When a connection is made, the counter is reset
Using a repeater, the connection is broken by the repeater, so the timer increase.
The problem is that the reset is done when a viewer connect...
So you see, after a while disconnecting the repeater make the server wait 30minutes before he reconnect again.
Re: Repeater/autoreconn - How to always-on reverse connectio
OK, perfect explanation. Thank you very much. Now the problem is absolutely clear.
But this means, the old repeater cannot be used for permanent reverse connection, or better, for permanent waiting servers.
A server that appears for 5 minutes on the repeater and disappears for 30 minutes cannot be used.
So, here are the requests:
* Please add a winvnc option in 1.2.0.8 to set the increment of the programmatic timeout (e.g. to zero)
* Please add a winvnc option in 1.2.0.8 to set socket depended TCP timeout (e.g. to 30 seconds or less) to fasten up the recognition of a drop by repeater.
Setting a socket dependent TCP timeout, which overwrites the system default, should be technically no problem.
We do the same for our own IP services used by different prisma applications to communicate with each other.
Do you think this would be possible? Or do you have a better and easier idea to solve the problem?
Cheers Greg
But this means, the old repeater cannot be used for permanent reverse connection, or better, for permanent waiting servers.
A server that appears for 5 minutes on the repeater and disappears for 30 minutes cannot be used.
So, here are the requests:
* Please add a winvnc option in 1.2.0.8 to set the increment of the programmatic timeout (e.g. to zero)
* Please add a winvnc option in 1.2.0.8 to set socket depended TCP timeout (e.g. to 30 seconds or less) to fasten up the recognition of a drop by repeater.
Setting a socket dependent TCP timeout, which overwrites the system default, should be technically no problem.
We do the same for our own IP services used by different prisma applications to communicate with each other.
Do you think this would be possible? Or do you have a better and easier idea to solve the problem?
Cheers Greg
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
Re: Repeater/autoreconn - How to always-on reverse connectio
There are some reasons for the timeout..
*programmatic timeout is needed to prevent 100% server cpu. ( else the server would try to connect 100x/sec)
But it can be set to 10-30 seconds
TCP timeouts...?
rcvtiemout: If no data is recv within 30 seconds, break.
Idle server sreen, no data send to viewer -> break
server wating for longer then 30 seconds -> break
viewer passwd popup ( accept/passwd) longer then 30 -> break
sndtimeout: This would detect a broken network faster if you send something...
A waiting server rcv, so this has no influence on the server waiting operation.
Changing the tcp default values lead to unexpected behaviour.
I don't think we need to change thoose parameters.
*programmatic timeout is needed to prevent 100% server cpu. ( else the server would try to connect 100x/sec)
But it can be set to 10-30 seconds
TCP timeouts...?
rcvtiemout: If no data is recv within 30 seconds, break.
Idle server sreen, no data send to viewer -> break
server wating for longer then 30 seconds -> break
viewer passwd popup ( accept/passwd) longer then 30 -> break
sndtimeout: This would detect a broken network faster if you send something...
A waiting server rcv, so this has no influence on the server waiting operation.
Changing the tcp default values lead to unexpected behaviour.
I don't think we need to change thoose parameters.
Re: Repeater/autoreconn - How to always-on reverse connectio
I meant to set the timeout increment to zero, to prevent having at last a timeout of 30 minutes. Sure, you can't retry suddenly, then you have 100% processor usage.Rudi De Vos wrote:programmatic timeout is needed to prevent 100% server cpu. ( else the server would try to connect 100x/sec)
How? Did I miss something in documentation?Rudi De Vos wrote:But it can be set to 10-30 seconds
Ok, if you don't think it's necessary, you'll know it best.Rudi De Vos wrote:I don't think we need to change thoose parameters.
I always talk about having parameters to ajust settings myself, if needed. I don't want touch any standard behaviour or defaults.
But I'm sure you agree, how permanent waiting servers work at the moment is less then optimal. I'd wish you'd have a good an simple idea to heal the symptoms.
(I know, new repeater wouldn't course this problem... He wouldn't kick the server, because he knows winvnc is alive. But we have many many old server out there... new repeater is no option)
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
Re: Repeater/autoreconn - How to always-on reverse connectio
There are no timeout parameters that can be set, i wanted to say that
A fix value of 20 sec is ok for 1.2.0.8 and that this would already fix 99% of the issue's
We re talking about server changes and no you say that you need to keep the old servers ... confused.
We can make a 1.2.0.8 server behave better , but then it would only solved for the servers running 1.2.0.8.
Perhaps some solution
Can't you run 2 repeaters
5500/5901/80
5501/5902/81
old servers connect to old repeater
new servers connect to new repeater
This is a simple change in the ini file... -connect ip:5500 or -connect ip:5501
But this has another issue, that you need to know the repeater port that's serving an ID
A fix value of 20 sec is ok for 1.2.0.8 and that this would already fix 99% of the issue's
But how do you expect a solution if nor the repeater or server can be replaced.A new repeater isn't an option for the old servers....correct
We re talking about server changes and no you say that you need to keep the old servers ... confused.
We can make a 1.2.0.8 server behave better , but then it would only solved for the servers running 1.2.0.8.
Perhaps some solution
Can't you run 2 repeaters
5500/5901/80
5501/5902/81
old servers connect to old repeater
new servers connect to new repeater
This is a simple change in the ini file... -connect ip:5500 or -connect ip:5501
But this has another issue, that you need to know the repeater port that's serving an ID
Re: Repeater/autoreconn - How to always-on reverse connectio
Your absolutely right, Rudi. If I was you, I would have been also completely confused. It's absolutely my fault.Rudi De Vos wrote:We re talking about server changes and no you say that you need to keep the old servers ... confused.
I missed to mention the most important. Sorry, due to hard work one forgets to focus on the essential:
We didn't had the requirement for permanent waiting servers until now. But now we have. And we would be able to replace the servers we need to wait permanent. But we aren't able to replace all the servers out there. That's no problem, not every server has to wait permanent. Optimally (!) all servers would use a single old repeater. For this reason we are looking for a solution with light improvements to new winvnc to better work with also the old repeater.
If you see a possibility to improve the behaviour of winvnc without enormous effort, we would very appreciate it. And we hope the community would have also some benefit from this improvement.
We will on our part discuss the possibility of operating 2 different repeaters.
For now thank you very much for your time and explanations. I'll come back to you very soon.
Cheers Greg
Re: Repeater/autoreconn - How to always-on reverse connectio
FYI: we "ended up" in serving 2 repeaters. But, to be honest, it's a good solution for us, possibly a better one.
We have now the benefit of being able to use the same IDs for permanent connections (e.g. at customers server, setup with new winvnc for second repeater) and "classic" on-demand connections (e.g. from an other computer in customers network, setup with old or new winvnc using old repeater)
THANK YOU VERY MUCH RUDI FOR YOUR PATIENCE AND IDEA!
We have now the benefit of being able to use the same IDs for permanent connections (e.g. at customers server, setup with new winvnc for second repeater) and "classic" on-demand connections (e.g. from an other computer in customers network, setup with old or new winvnc using old repeater)
THANK YOU VERY MUCH RUDI FOR YOUR PATIENCE AND IDEA!