Do you seriously expect that your viewer will be only used with same version host? Don't make that mistake. Viewer should be as much backward compatible as reasonable possible.
It is backward compatible enough to update the Host as soon as possible. But we cannot guarantee 100% compatibility when there is version mismatch simply because new features implemented in the newer version are not available in older Hosts (we cannot travel into the past and inject them in that host :) ).
If it is not possible to update the Hosts in reasonable time it is recommended to stay with the current Viewer then. It doesn't make sense to update Viewer only.
Regarding this specific issue - if you cannot update the Hosts then you should roll back to your Viewer 6.8 and try to reproduce the issue. We cannot troubleshoot this problem if there is version mismatch because we cannot know why it happens - that is whether there a "stand-alone" bug or it's an issue caused by version mismatch.
I am using a 64bit Windows 10 OS and I am constantly getting disconnected as well. I am seeing online this is a common problem with your application, and has been for quite awhile, is there any plans for fix this, or to help use determine what needs to be done to stop these disconnects? I really like your product, however, I would not even entertain the idea of purchasing it when the time comes that I get over 10 clients. Unfortunately, I would have to go with "the other guy"
We received the log, thank you. However, the log shows connection attempts to our public server (id.remoteutilities.com) rather than any self-hosted server address. This discussion is about self-hosted server.
Still, even if you use the public server I can see that the Host has issues connecting to the server. There is socket error #11004. Here is from Microsoft site:
WSANO_DATA 11004 Valid name, no data record of requested type. The requested name is valid and was found in the database, but it does not have the correct associated data being resolved for. The usual example for this is a host name-to-address translation attempt (using gethostbyname or WSAAsyncGetHostByName) which uses the DNS (Domain Name Server). An MX record is returned but no A record—indicating the host itself exists, but is not directly reachable. https://msdn.microsoft.com/en-us/library/windows/desktop/ms740668(v=vs.85).aspx
Please, check that the dns name of the server is resolved properly on the Host computer. I recommend flushing the dns cache and also check your network settings, e.g. set Google DNS servers instead of your ISPs in your TCP/IP properties.
I am seeing online this is a common problem with your application, and has been for quite awhile, is there any plans for fix this, or to help use determine what needs to be done to stop these disconnects? I really like your product, however, I would not even entertain the idea of purchasing it when the time comes that I get over 10 clients. Unfortunately, I would have to go with "the other guy"
In order to find the reason why disconnects occur we need to examine the logs, mainly the Host log. Could you please send it to email@example.com .
Also, RU version 6.9 beta 2 and Server 2.7 beta 2 are available for download. If you can, please update and let us know if the issue persists. Not that if you decide updating you should update all modules, not just the Viewer or server.
The only "issue" (well, actually just a lack of a feature) is that you cannot use "Simple update" to update your Hosts remotely once you updated the Viewer because this feature was implemented starting version 6.6. Otherwise, the update process should be ok.
Any particular instructions in performing the upgrade on the Hosts other than the 'check for updates' option? Loosing connectivity is not an option to most based on location and timing of accessibility. All Hosts are running either Win7 or Win10. Thanks
A rule of thumb when remotely updating your Hosts is that you update the Hosts in small groups and keep control over the process. First, you upgrade the Viewer, then you upgrade one or two Hosts to test the procedure and see if there are any adjustments you should make to your process, and then proceed with updating the rest of the Hosts (every 10-20 Hosts at a time).
That said I highly recommend that you wait another two weeks and update to version 6.9 when we release it. There were quite a few important changes as compared with version 6.8, see the release notes as well as the recent posts in our blog.
Having said that, it seems rather backwards to me. I can think of all kinds of bad things happening if a rogue viewer (controller) connects to a given host, but I have a hard time picturing the same type of concern that I've connected to the wrong host.
I see. And yet, the host identity mechanism as it can be seen in version 6.8 and earlier was to prevent just that - unauthorized replacement of the Host with a rogue/patched copy.
Perhaps I could add this 'shared secret VIEWER verification' option as a feature request. This way I could honestly tell clients/customers that no other RUT viewer can get to their computer. That their host would speak to ONLY MY viewer. The current implementation (and the certificate based scheme in the beta version) does not offer that assurance.