Community

Conrad wrote:

So this might have something to do with the resolution of your server's DNS name inside the same network where the server is. This brings us to the "loopback" problem when a service tries to resolve an external IP address from the inside.

I think you nailed it. I, as a test, went into my Viewer and renamed the server DNS address with the local IP of the server and my contact immediately appeared online.  I can ping my server DNS name from the command prompt from within the network and get a response. It responds with my public IP address.

I just tried ipconfig /flushdns on Viewer and Server, nothing changed.

I'm really perplexed by this issue. It used to work fine on the old modem in network and out of network.  I'm using noip.com for dynamic DNS and the app is running on the server keeping the IP address updated with the domain name.

Hi Conrad,

Thanks for your response.

I am able to ping my server PC. It is using a dynamic DNS and I can ping that address on my Viewer PC and receive a response.  They are both on the same network.

The only thing that changed from when it was working to now was the router controlling DHCP.   I was careful to assign the new router the same IP range, the same static IP's I had before and the same port forwarding parameters.

Yesterday Spectrum had to come do some work on the cable connection and upgraded the cable modem to Wave 2 router. I forwarded port 5655 to my dedicated server as it was before but now when I am connected to the same network on the Viewer the clients all appear offline. If I connect my Viewer PC to my cellular hotspot network the clients on the dedicated server appear online and are connectable.

I don't know what is wrong. Can someone please help me figure this out?

Many thanks,
Nijel

I just wanted to update everyone that I made a change to my network which seemed to clear up all of my issues that I was having before, the network cable wasn't it, I can now work wireless or wired with no noticeable difference.

I reconfigured my network to have only one DHCP server and one NAT enabled router (both the same device).  Since making this change many things improved including faster more reliable Xbox live connections, and, more importantly, the strange unreliability and stuttering issues while working remotely through my self hosted server abruptly ended as soon as I made this change.

The connection to my RU server used to travel through an unmanaged switch, to a Netgear router 192.168.1.1 with DHCP enabled, NAT "Open", to the cable modem/router combo 192.168.0.1 (DHCP, NAT'd). I have two other routers and they are connected to the Netgear router which was previously 192.168.1.1 and their LAN IP's were ending in .3.1 and .4.1 respectively, both were DHCP enabled. Now everything is on the same 192.168.0.1 IP table and it's running great.

It's been a few months since I made this change, sorry for the late update. I hope this helps others who may be experiencing the same stuttering/dropping/unreliable connections on a self hosted server.  Make sure your network isn't too "smart".

I ran a network cable to my laptop's workstation and that seems to have improved performance. Also setting color to 8bit and processor usage to FPS or High seems to help. I think the main problem may be WiFi interference. There are several hotspots in proximity to me here and although I never have issues with normal web browsing on WiFi, I noticed a substantial increase in performance with my remote work when I switched to wired.

The server and all hosts, and the viewer are using the latest version of the software.  I experience slow performance on most sessions, so much so that it becomes unusable.

I can connect to the same clients using a different method and the performance is very good, almost real time.  What sort of connection problems could affect only this program?

I have RU on over 30 machines and it's fairly predictable that I will need to reconnect several times to get anything done. Extremely delayed responses opening programs. I've run two remote programs simultaneously and observed double clicking a program on RU, switching over to watch the program open on remote desktop, and switching back to RU to see nothing happening for several seconds to several minutes or not at all.

Reconnecting sometimes makes it work faster but it often hangs. I haven't configured callback settings, is that supposed to help performance?

I'm experiencing erratic performance, connections dropping or becoming unresponsive. It's very erratic; sometimes it's quick other times it's unresponsive.  Disconnecting and reconnecting seems to help in the short term but after being inactive for a short while the remote computer is unresponsive and needs to be reconnected to.

I've observed this behavior using the default server and a self hosted RU server.

Is there any path I can take for improving performance?

Thanks, Nijel

Very embarrassed I did forget to change my Viewer settings from Default to my dynamic dns server. I thought I had done that but I must have overlooked it. I'm getting connectivity now! Phew!!

After configuring my self hosted server and hosts I am unable to connect to the hosts through the Viewer.  On the server side I can "see" the hosts as all idle. The server lists the IP addresses and PC names but on the viewer I am unable to connect to them.

I'm sure that my dynamic dns is running on the server and the Viewer information is correct with the "default server" unchecked and my dynamic DNS name in the custom server type box.

I'm sure that port forwarding for 5655 is done both on my cable modem and on the router the server is plugged into.

I disabled all firewalls and Ddos protection on the router and cable modem to see if that was causing issue but nothing changed. (I re-enabled those settings afterwards)

The windows firewall is off on the server.

I can't think of anything else to do.  The most interesting part of this is apparently the server can see the hosts but the hosts can't be connected to.

Please help!

Thanks,
Nijel

Thanks Conrad! Everything went smoothly.