Community

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

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.

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.

Hi Max,
This may be old now, but if I may provide my 2cents.
I have made host2host direct connections due to non-attendance equipment monitoring PCs.
Host1 is direct connected to Host2.
Host 1 and Host2 is also on an iD server (in the company's server) for me to connect to it for iTSupport from internet.
If I want to I can do a direct connection into Host2 as well.

I did this because previous version of RU is slow, so I want to bypass any servers or internet speed issues. However, doing this requires port forwards.

RU cascades, I just found out reading this post.
I have been running RU iD Server on host machines. Then I only do 1 port forward and then its an internal LAN connection between server and hosts. Server on host is invisible to the server host user. It does not slow it down in anyway, caveat, dependencies on good LAN switching/wifi equipment.