Repeater/autoreconn - How to always-on reverse connection?

[Prisma]

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?

[Rudi De Vos]

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.

[Rudi De Vos]

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.

[Prisma]

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?

[Rudi De Vos]

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.

[Prisma]

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.

[Rudi De Vos]

The time is the default tcp connect() timeout value ( OS depended ), this is very long.

[Prisma]

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?

[Prisma]

OK, I dug deeper.

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

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?

[Rudi De Vos]

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.

[Prisma]

Ok, tested with local LAN connection, no firewalls, not even a Windows firewall, NATs etc. in between.

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, 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.

He doesn't know the socket is broken, and keeps waiting until some timeout close everything.

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?

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]

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.

[Prisma]

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

[Rudi De Vos]

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.

[Prisma]

programmatic timeout is needed to prevent 100% server cpu. ( else the server would try to connect 100x/sec)

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.

But it can be set to 10-30 seconds

How? Did I miss something in documentation?

I don't think we need to change thoose parameters.

Ok, if you don't think it's necessary, you'll know it best.

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]

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

A new repeater isn't an option for the old servers....correct

But how do you expect a solution if nor the repeater or server can be replaced.
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

[Prisma]

We re talking about server changes and no you say that you need to keep the old servers ... confused.

Your absolutely right, Rudi. If I was you, I would have been also completely confused. It's absolutely my fault.
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

[Prisma]

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!