Remote Support
Remote Access
Monitoring and Management
Presentation
Remote Work
Standard
Business
Enterprise
Direct TCP Connections
When establishing a session to a remote machine, the SimpleHelp session client will attempt various types of connections in preferential order. By default it will establish a basic connection then attempt to upgrade the session to Direct TCP. You can alter this behaviour in the Preferences tab in the technician client.
TCP Direct
TCP Direct connections go directly from the Technician app to the remote machine. Both sides will still maintain minimal communications with the SimpleHelp server but the data transferred during the session will not go through your server.
This typically reduces latency (lag) in the connection to a minimum and also reduces the network load and bandwidth usage on your server.
SimpleHelp sessions will by default try to upgrade to TCP Direct if a TCP session was established, or you can request it attempt one specifically in the right hand pane in the session window, by expanding the connection details bar.
Where possible SimpleHelp will use a consistent port range of 15330-15400 to establish these connections. If you are failing to acquire TCP Direct connections you should first ensure both sides have outgoing direct TCP access (not purely HTTP proxied for example) and then open the port range on either or both of the local Technician Console or remote machine.
Even with the port range open for incoming connections there may still be other network issues that prevent a direct connection from being established. For example if both sides are behind a NAT (e.g. a router) and are not on the same LAN, the connection may fail as neither side can directly reach the other.
UDP Direct
In cases where you cannot use TCP or TCP would not perform well (connections with very high latency or packet loss) the best possible connection is usually a direct (point to point) UDP connection. This does not go through your server (which saves bandwidth) and it requires the following:
- That your server is accepting incoming UDP packets on all its listening ports
- That both sides of the connection are able to make outgoing UDP connections on all ports
- That on at least one side of the network no network routers or firewalls are doing port rewriting (randomizing the outgoing port to prevent prediction of the port used on future connections).
If your server can accept incoming UDP packets and both sides of the connection are allowed outgoing UDP connections on all ports then you should consult your network router / firewall documentation or manufacturer to disable port rewriting / randomization.
Settings for this may be available under outbound NAT, static port, port rewriting, port randomization, advanced NAT or similar and settings may need adjusting on any or all routers or firewalls passed through (on one or other side of the connection). Additionally if your firewall or router has software to prevent port scanning it may be necessary to adjust or disable it.
UDP via Server
The next best connection type for a network with high latency or packet loss is a proxied (via your server) UDP connection. This is almost as fast as a UDP direct connection but may have more latency (geographic time delay for the data to travel between you and your customer).
To ensure this type of connection is possible you need only ensure that:
- Your server is accepting incoming UDP packets on all its listening ports
- You and your customer are able to make outgoing UDP connections on your server's listening ports
Manually requesting connections
In some cases you may find that routers or other network security hardware or software respond badly to UDP connections. This can be the case if they have "UDP Flood Protection", "UDP DoS Protection" enabled or similar. In these cases you may find the connection becomes unstable when operating over UDP. In such cases you can disable UDP upgrades from the Preferences tab in the Technician Console and/or you can open the tuning dialog in the session and manually request that SimpleHelp use another connection type, then try out the various alternatives to determine which is the best.