Once I updated hosts and viewer to v6.10.x.x. this problem was _virtually_ eliminated - though not completely.
HUGE IMPROVEMENT: I'm no longer seeing constant disconnections every few minutes. BUT: I do sometimes get a disconnect once every few hours which is tolerable.
However I will share an observation that I shared in my post to this discussion on Mar 29, 2019:
Very often, the main RU window listing connections will show a pop-up saying the remote connection has disconnected. However for up to 5 seconds, I can continue to fully interact with the remote system in the viewer, whether that's typing text, moving windows, clicking UI, etc. before the remote connection actually drops.
Once I reconnect to remote system, I can confirm the actions taken *after* RU reported the connection had dropped were indeed performed on the remote system.
To me this suggests it's not so much a case of the remote system has disconnected, but that something (other than the host or the viewer) has *decided* the remote system has disconnected. This is undoubtedly an over simplification, but it seems to me the host & viewer would ideally be the final determinants of a dropped connection.
Edited:Greg Sullivan - Sep 08, 2020 10:14:36 am EDT
First off, RU is an awesome product. Overall, very happy with the flexibility it allows me.
I've had this 'disconnect' issue as well. So far I've seen this persist with 6.8.x.x and 6.9.x.x. I'm currently in a situation where I can't risk attempting a remote upgrade to 6.10.x.x that might fail where I completely lose remote access. So that'll have to wait - but it sounds like 6.10.x.x are still seeing it. So I'll share some observations.
This seems to be more nuanced than just simple "network issues" at the host or viewer ends. The viewer is on a 1 Gbit (roughly symmetic) fiber internet connection. The host was initially on a admittedly spotty DSL connection, then upgraded to more stable a 50 Mbit cable internet. The problem remains the same.
Early in the day (east coast, US) remote connections are pretty solid - around 1 PM EDT they start dropping. During this time, bandwidth and latency do drop a bit, but overall do not show any drastic degradation. Around 6 PM EDT, things start improving.
A few observations: 1) If the viewer connects to the host by Internet-ID, the connection fails several times an hour. 2) I can immediately connect my local computer to the host computer network over VPN and the connection no longer fail. The VPN server is hosted at the same location / network as the host computer. So at a high level, there's not a drastic change in the connection between the two points - except the use of the Internet-ID. 3) Recently, perhaps most significantly (?), I've noticed that when the connection drops, the main Viewer window displays the "connection error" and the remote host either shows as "Online" (but no longer "Logged On") or briefly moves to "Offline/Unknown" before moving back to "Online". However, while all of this is happening, for 2 to 4 seconds, I can continue to interact with the remote desktop. After a few seconds, the remote desktop does eventually "drop". Upon reconnecting, I can confirm that the actions taken after the "disconnect message" were indeed carried out on the remote host.
This would suggest to me that the issue isn't so much in the remote access connection, but in Internet ID connection status mechanism. It seems that for some reason, the viewer determines [incorrectly?] that the remote host has gone away and closes a functioning remote access connection.
Sorry to report we too are also [still] seeing random disconnects, and frequent online/offline popups over the past two days.
In my experience, prior to v126.96.36.199, the issue was far less common. Also, I do wonder if there's a "network health" component to the problem: - With remote machines at two locations, the issue seems to be much worse at the location that has a lower bandwidth, and less stable connectivity. - At this "worse" location (Eastern US time-zone), the problem is almost non-existent prior to 12:00 or 13:00, at which point it gets quite bad and remains so until around ~19:00. Weekends are usually problem free. I've wondered if net usage in local geographic area is a factor. - It's a far less desirable configuration, but if I establish a VPN connection to this "worse" location, and connect to the remote station by local IP instead of Internet-ID, the issue is reduced (eliminated?).
Initially, I was planning on trying to get hardware pulled together to set up a local server, but this will be a challenge in the near term - and reading this thread might not solve the problem.