HPR Deployment Considerations and Options

This page goes into detail on the various considerations for deployment, and the options that you can use for the HPR Server.

 

Deployment considerations

Multiple HPR Servers

Parsec allows for multiple HPR servers to be added to a single Teams account. Multiple HPR servers can be specified for the entire account or per group through adding the LAN IP or DNS addresses and ports separated by a comma (format HOST:PORT,HOST:PORT) in the Teams admin portal. If you want specific people or hosts to go through certain HPR servers only, you can specify HPR servers in an App Rule, then assign the App Rule to the person or host.

If multiple HPR servers are available, hosts will automatically select the one with the lowest latency. If no HPR server is contactable, hosts will fall back to the public STUN server unless app_force_relay is set. If you never want hosts to fall back to the public STUN server, you can prevent that behavior by setting app_force_relay in the hosts' config files.

For high availability, it is recommended to have more than one HPR server specified for each computer. There may be times when one HPR server needs to go offline, such as when it needs updating. Having a second server available to handle connections would prevent disruptions to users in these instances.

When adding a second HPR server, you'll need to plan your deployment to avoid NAT conflicts. If each HPR server gets a unique public IP, it doesn't matter if you use the same ports for each one. However, if both HPR servers are behind a single public IP, you will need to use a different public port to avoid conflicts.

DNS support

It is possible to use DNS records to configure HPR candidates for Parsec hosts. The DNS value can be configured in multiple locations, such as the following:

  • Admin panel (High Performance Relay server host address)

hpr_team_panel_host_addresses.png

hpr_registry_editor_configuration.png

hpr_config_txt.png

Multiple HPR candidates

Parsec hosts wills end a UDP ping to each relay candidate and select the lowest latency candidate. This is helpful if there are multiple HPR servers configured in different geographic locations, enabling the hosts to pick the closest relay.

Fallback to public STUN

If Parsec host is not configured with an app_force_relay setting in the configuration file, the host will fall back to using Parsec's public STUN server for connection negotiation if the local relay server(s) are unreachable. This helps in scenarios where machines are moved between locations that have relays and locations that do not have relays. For example, a host that was on a corporate network, but was subsequently moved to a home network.

 

Advanced connectivity scenarios

A user and a host each have an App Rule assigned with different HPR servers specified within the admin portal. When the user attempts to connect to the host, the HPR server specified for host will be used. The host machine will always use the config of the App Rule over the App Rule assigned to the user - in this case, the host isn't even aware that the user making the connection is assigned an App Rule with a different HPR server specified.

 

Force client connections through relay server

Parsec's default connection negotiation behavior can result in a successful P2P connection without using the relay if the host peer has outbound UDP connectivity to the internet and the client peer's router/firewall supports UPnP or UDP hole punching. If you'd like to disable this behavior and force all P2P traffic over the relay, you can add the following line to your host peer's config file or registry and restart Parsec:
app_force_relay = 1
If you'd like to force all traffic from the internet (WAN) to use the relay, but still allow the host to accept "direct" LAN connections, you can add the following line to your host peer's config file or registry and restart Parsec:
app_force_relay = 2

Please note that this should only be set in the host's config file and not on the client machine.