MaxBlitzer's community posts

Conrad wrote:

Hello Max,

Yeah, I don't think you understand what I mean, because businesses would definitely prefer to run traffic between their hosts directly and not through another server unless they had to. We'll just agree to disagree on that. Perhaps if I was unclear, all I really meant is that connections be made using direct connection, but without the user having to configure anything, it is handled automatically by the server. But I do believe you answered my question by not having any plans to implement such a feature. Fair enough.

Perhaps, cascade connection  may qualify as such a feature.

Thanks.

Thanks, that would be very useful for places with more than one machine and I'll look at setting that up in once place.  But not so much when target computers are at different locations.

If you mean peer-to-peer connectivity though, I am sorry but this is not the way to go for us. It might work for free and personal tools, but since we also sell to businesses they won't be happy to use a P2P application due to security concerns that such applications can bring.

Yeah, I don't think you understand what I mean, because businesses would definitely prefer to run traffic between their hosts directly and not through another server unless they had to. We'll just agree to disagree on that.  Perhaps if I was unclear, all I really meant is that connections be made using direct connection, but without the user having to configure anything, it is handled automatically by the server.  But I do believe you answered my question by not having any plans to implement such a feature.  Fair enough.

A ping fr om your location to our server doesn't say anything about the quality of the server itself. Our servers can sustain far more load than now and are located in one of the largest datacenters in Canada.

Yeah, I failed to make my point clear again, unfortunately.  You could have the single greatest server in the world, but it means very little if the Internet pipe leading to it has problems (like throwing a party when the roads are washed out and the guests can't arrive).  The data I showed you indicated it wasn't your server, but the pipe leading to your server. And I further pointed out that all your server metrics about how lightly loaded and how fast your server is is not going to show this problem. I can only anecdotally report that I have found repeated, very high latency problems.  You did make a point of saying you have a world class data center, which may be true.  But that doesn't change the fact that the Internet regularly has congestion and routing problems and this is a real world problem.

Because I ended up with the relay server that was further away by distance, latency, and reliability it makes me curious whether if the relay server pick is just simply 'you're in Canada, here is your relay' (which isn't the case, since I do see the Cali IP sometimes), or if there is load balancing going on (a problematic data center would show very low load, possibly making your load balancer send more and more hosts to it, exacerbating the problem).

We recommend that you use a self-hosted server or even direct connection wh ere possible.

I understand that. But that just means it'll still be relayed through my connection instead of directly between users. So it will help a lot, but not avoid the problem. It shifts the server maintenance and cost to me (which isn't unfair, you're making a free product). I have endless linux servers both locally and in closer datacenters and if you had a server that ran on linux, I'd be all over that.  But you've also stated that isn't a priority.  For the low amount of usage per month, I can't say I'll be doing that. The time alone on maintenance of the server would be more than amount used.

I appreciate the thorough and honest replies. Thank you.

p.s. the forum seems to be inserting some spaces and eating some letters here and there.

Are there any plans to implement a service to facilitate direct connections between hosts instead of connections relaying through your servers unless manually setting up port forwarding and using direct IP's?

The benefits for RUT is the lower bandwidth and server requirements due to less relaying, and much faster performance between direct hosts.

I've frequently ran into performance issues through the various relays used by Remote Utilities.  Way, way, too frequently.  The latency is high and there is significant ping loss. I have a PC next to me that I'm connecting to that has more than 8 seconds of latency (it's varied fr om 4-18 seconds while I've been writing this). The re's the scenic login screen and then the computer boots up with Spotify open and the large pictures seem to bring it to a crawl even with 16 bits colour. I have it on HDMI output to a monitor on my right, and then connecting using Internet ID fr om my main PC next to it.  At this moment, round trip ping time to your relay server in Montreal is 163ms (from west Canada. I normally get 78ms pings to Ontario, so this Montreal hub kinda sucks as you'll see below) with approx 18% packet loss.  

Reply from 108.163.130.184: bytes=32 time=163ms TTL=113
Reply from 108.163.130.184: bytes=32 time=162ms TTL=113
Request timed out.
Reply from 108.163.130.184: bytes=32 time=167ms TTL=113
Reply from 108.163.130.184: bytes=32 time=161ms TTL=113
Reply from 108.163.130.184: bytes=32 time=164ms TTL=113
Reply from 108.163.130.184: bytes=32 time=165ms TTL=113
Request timed out.
Request timed out.
Reply from 108.163.130.184: bytes=32 time=161ms TTL=113
Reply from 108.163.130.184: bytes=32 time=164ms TTL=113
Request timed out.
Reply from 108.163.130.184: bytes=32 time=162ms TTL=113
Reply from 108.163.130.184: bytes=32 time=171ms TTL=113
Reply from 108.163.130.184: bytes=32 time=162ms TTL=113
Request timed out.
Reply from 108.163.130.184: bytes=32 time=165ms TTL=113
Reply from 108.163.130.184: bytes=32 time=163ms TTL=113
Request timed out.
Request timed out.
Request timed out.
Reply from 108.163.130.184: bytes=32 time=168ms TTL=113
Request timed out.
Reply from 108.163.130.184: bytes=32 time=164ms TTL=113
Reply from 108.163.130.184: bytes=32 time=162ms TTL=113
Reply from 108.163.130.184: bytes=32 time=164ms TTL=113
Reply from 108.163.130.184: bytes=32 time=162ms TTL=113
Request timed out.
Request timed out.
Reply from 108.163.130.184: bytes=32 time=173ms TTL=113
Reply from 108.163.130.184: bytes=32 time=163ms TTL=113
Reply from 108.163.130.184: bytes=32 time=162ms TTL=113
Reply from 108.163.130.184: bytes=32 time=164ms TTL=113
Reply from 108.163.130.184: bytes=32 time=162ms TTL=113


pathping /n /4 108.163.130.184

Tracing route to 108.163.130.184 over a maximum of 30 hops

 0  192.168.2.20
 1  96.55.x.x
 2  64.59.152.37
 3  66.163.69.197
 4     *     66.163.76.66
 5     *        *     69.174.2.41
 6  141.136.105.209
 7     *     199.229.229.62
 8     *        *     184.107.1.122
 9  184.107.1.38
10  108.163.130.184

Computing statistics for 250 seconds...
           Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
 0                                           192.168.2.20
                               0/ 100 =  0%   |
 1    8ms     0/ 100 =  0%     0/ 100 =  0%  96.55.x.x
                               0/ 100 =  0%   |
 2   10ms     0/ 100 =  0%     0/ 100 =  0%  64.59.152.37
                              13/ 100 = 13%   |
 3   89ms    21/ 100 = 21%     8/ 100 =  8%  66.163.69.197
                               0/ 100 =  0%   |
 4   92ms    20/ 100 = 20%     7/ 100 =  7%  66.163.76.66
                               0/ 100 =  0%   |
 5   92ms    17/ 100 = 17%     4/ 100 =  4%  69.174.2.41
                               0/ 100 =  0%   |
 6  154ms    19/ 100 = 19%     6/ 100 =  6%  141.136.105.209
                               0/ 100 =  0%   |
 7  ---     100/ 100 =100%    87/ 100 = 87%  199.229.229.62
                               0/ 100 =  0%   |
 8  ---     100/ 100 =100%    87/ 100 = 87%  184.107.1.122
                               0/ 100 =  0%   |
 9  167ms    30/ 100 = 30%    17/ 100 = 17%  184.107.1.38
                               0/ 100 =  0%   |
10  163ms    13/ 100 = 13%     0/ 100 =  0%  108.163.130.184

Trace complete.

tracert 108.163.130.184

Tracing route to jobiworks.com [108.163.130.184]
over a maximum of 30 hops:

 1     *       12 ms     9 ms  96.55.x.x
 2    10 ms    11 ms    13 ms  rc1st-be117-1.vc.shawcable.net [64.59.152.37]
 3    90 ms    92 ms     *     rc1bb-tge0-0-0-28.vc.shawcable.net [66.163.69.197]
 4    93 ms     *        *     rc1wt-be90.wa.shawcable.net [66.163.76.66]
 5    93 ms     *        *     ae10.cr2-sea2.ip4.gtt.net [69.174.2.41]
 6   157 ms   159 ms     *     et-3-3-0.cr0-mtl1.ip4.gtt.net [141.136.105.209]
 7   167 ms     *      163 ms  iweb-gw.ip4.gtt.net [199.229.229.62]
 8   164 ms   163 ms   168 ms  po22.cr4.mtl.iweb.com [184.107.1.122]
 9   177 ms     *      166 ms  te8-4.dr7.mtl.iweb.com [184.107.1.38]
10   161 ms     *      162 ms  jobiworks.com [108.163.130.184]

Trace complete.

For some other services like router/NAS logins from the cloud or VPN services I use, in their automatic direct connection stuff, I'll start a ping to a client machine and pings will be 100-500ms for about 8 pings, and then drop to 12ms-23ms (depending on if using same ISP as me or the 'other' ISP in our town) as the connection no longer uses the relay.

I believe you also have a relay server in California, which is closer and lower latency, approximately 50ms with no ping loss so far. So I'm not sure how hosts pick the relay servers, whether its random, first to respond, round robin, or load balanced, etc.  But there is very clear and poor performance using the relay server and I don't see a way for me to bounce it to a better relay server and I don't see anything happening on the server side to migrate me to the better performing server that is 1/3 latency and without packet loss.

As of this moment, the packet loss has stopped (and pings down to 82ms from 162ms) and the responsiveness is back to wh ere mouse movement is not noticeably lagged, buttons respond, windows draw, etc.  UAC prompts are still 6-8 seconds slow, though.  I'd say the issue was approx an hour or so before it cleared up. So if you're only thinking servers are good because they are online only and not the quality of the connection, then users are going to continue to experience poor relay performance.  Congestion and outages can happen many places along the path wh ere your server is up and running fine (or even being under served due to datacenter bottlenecks). I recall previously when complaining about very high lag that you checked and your servers were not experiencing any high loads or issues.  This fits when the problem is not at your server but along the Internet pipes.

(p.s. Yes, I know I can direct connect since its on the same LAN, but the PC is just getting driver updates then powering down and going back to my nephew and it's already in my viewer. If it was going to be a headless machine in my own home, then taking the time to do direct connection makes the most sense.)

I've been using Remote Utilities for a couple of years here and there.  Unfortunately, I just don't see improvements and get annoyed by some little things. Here is my feedback:

1. I can't have Viewer open all the time because I get too many "... is Online" pop ups. All connections are on broadband cable with no known network issues. Happens to different users.  Popped up 3 times in the few minutes I've been drafting this message so far.  (Probably over 10 popups during the rest of this drafting).

2. The Last IP doesn't show the last IP that the user used, or were NAT'd behind. My best guess is that its one of your relay servers, but I don't know why you'd have a column dedicated to that when the last seen IP of the user would be more more useful.  Really confused me one time when I didn't realize the numbers were bogus. But add some more clients located in different locations and show the same IP for iWeb in Montreal. We're all in BC, Canada.  After writing this, I checked the viewer again and the Last IP changed again for the computer that is going on/offline over and over. This time, the IP is registered to CariNet out of San Diego. For 4 online users in the same town as me, there are 3 different Last IP's. The two that are the same are from two offices on the same road, so at least they are together. Since this is the last IP of your relay servers and not of the actual client, it clear the user is getting bounced around on different relays. It would be good if you posted your server locations, as last time I experienced serious lag I looked into going self hosted, and the pings to your relay were like 28ms or something (I thought you had a relay in Seattle, but I must be mistaken).  Now they are 80-90+ms for all 3 relay servers. So now I think I should look into self-hosted to avoid this relay bounce.

3. For one Win10 machine, logging into it is SOOOOO slow. So many times I would get failed logins because the time between typing the password and the character registering in the windows 10 login box would be in SECONDS. No change after at least 3 version updates. You just can't work on lag that I haven't experienced since 1998.

4. The default screen size/ratio needs to be changed more often then not. With TV, I never have to mess with scaling, I just maximize the window or I snap to half screen.  No needing to scroll vertical or horizontal bars by default except with Remote Utilities.

5. If I don't experience really laggy logins, I still experience laggy mouse movements.  Was so frustrated when I had to use it today. I don't think that PC had a password set, so I don't know if that had the really laggy login and might just be same as issue 3 above.

6. In previous versions, remote access broke by Windows updates, I believe. Requiring re-installation and manual intervention and lost headless access.  But I'm guessing that was a hard lesson learned and will be prevented from happening again by installing the software in the appropriate places from now on.

I haven't paid RU any money so I don't feel like I'm owed support or anything.  Just that these issues have prevented me from investing in a RU license and commit to it.  Rather than sink some hours into troubleshooting these issues (besides other conflicts, like computer availability for testing, frequently changed login passwords, changed users, powered off PC, etc), I just fallback to existing resources I have available (openvpn, neorouter, VNC, TV,  [censored] , etc) and wait on new versions to try.

I saw in one of the other forums that you have identified some server bugs and that a new release is imminent.  I look forward to trying that new version and hopefully resolving the lag issues.

I don't know what additional access I can have to the PC, but you can move this thread to ticket and I'll try on a best effort basis to collect some info.  I don't want to muck with their screen/display settings, sorry.

Viewer and host running Win10. The windows login screen has a random wallpaper that comes through with high quality. It looks like the relay I'm using is on US west coast and ping times are 32ms.  So it doesn't look like latency issue.

Vancouver, BC Canada area for both.

Thanks

I occasionally use RU to login to headless machines every few months as needed.  When I logged into a few machines the last few days, the responsiveness has been very bad.  It makes it hard to enter passwords and other things when there is like 3-5 second delay between key press and when it appears on screen.  I've NEVER experienced lag so bad, and I regularly use TV with 2 RDP sessions.

I'd like to know the IP of the public server or at least the location so I know whether I can setup my own server closer and get better speeds.  I have a bunch of Windows servers but they have 80ms round trip latency.  

If I was a paid Mini Operator, does that get faster relay speed than if using free license?

Thanks

Conrad wrote:

Also, you should "unblock" (windows protection) the msi files before you zip them up. It should only be necessary for the downloader to unblock the .zip, and not have to do it for the individual files as well.

Could you please elaborate more on this issue, what unblocking do you mean? By the way, you can also download files separately from the same page (Viewer, Host etc.).

Hmm, looks like my bad.  I just re-downloaded the full .zip package and couldn't reproduce the issue. Basically, what I saw before was that I unblocked the .zip (through the file's Properties), but still got the Windows pop up that the file may not be safe for the individual .msi's. My conclusion is that when I thought I unblocked the .zip prior to unzipping the msi's, it didn't actually.

So ignore that.  PEBKAC

Regards

In the Viewer and Host, Help->About says:

Version: 6.4.0.2 beta 2

Why call it beta 6.5 if its beta 6.4? That's confusing if its not a bug.

Also, you should "unblock" (windows protection) the msi files before you zip them up. It should only be necessary for the downloader to unblock the .zip, and not have to do it for the individual files as well.

Edit: Just saw that you responded on Aug 17th that this versioning is expected.  My 2 cents, DON'T.  Just call it a 6.4 BETA and stable release as 6.5.  I'm not aware of any other company/software that does beta versioning like this.  You're just asking for confusion by having mismatched version strings.