It will save all of us time when figuring out the problem. Note that Remote Utilities is software of "dual nature". A connection involves at least two and sometimes (in case of ID connection) - three modules including an ID server. So we need logs from all of the modules along with the date and time of when the issue happened.
The Viewer log alone won't help us figure out the issue. We also need the Host's log and other information. If you wait a bit we will come up with a detailed instruction in our knowledge base on how to collect the necessary logs and what to send to us. I will provide a link to the knowledge base article later today or tomorrow.
Is there a way I can download an older copy of the viewer, as some have stated running an older version fixes this issue?
Downgrading to an older version is not recommended. Besides, before we examine your complete logs we cannot be sure if your issue is the same as the one reported in this thread.
Let me draw an analogy - a high human body temperature is a sign that something is wrong, but it can be caused by many factors (specific illnesses). The same is true about a connectivity problem - on the surface it looks the same, but the cause might be different in each case, although there are not many of them actually.
- 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.
This might be a factor.
- 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.
Yes, perhaps. Our servers can sustain far more load than they experience now so it is very unlikely that the time of day has any significance when it comes to servers themselves.
- 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?).
Currently, we are working on a 64-bit server version and it is already available for testing. I recommend that you replace your current server with a 64-bit version and test to see if you still have issues. Here is how:
1. Back up your server installation folder - just copy it elsewhere
I am constantly getting drops, did a constant ping, and never took errors and was constantly around 30ms or less.. But sites just randomly disconnect for no reason.
I would recommend that you create a separate thread/topic devoted to self-hosted server connectivity issues. Or you can join this topicthat reports a similar issue. We need to keep self-hosted server issues separate from public server issues as they are dealt with differently.
The old version of RU Server download is all that is available, Version 22.214.171.124, August 26, 2017. Conrad, Can please clarify your response, when will the update apply to RU server download? Thanks
RU Server hasn't been updated. What was updated is our public server infrastructure. So we are asking everyone who contributed to this thread with the "online/offline" problem to report if the problem has been resolved now.