Deployment Considerations and Options

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 groups to go through certain HPR servers only, you can specify HPR servers per group under that group’s settings. 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=1 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=1 in the hosts' config files.

For high availability, it is recommended to have more than one HPR server specified for each computer, whether that be through groups or the Global App Settings. 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:

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:

Scenario 1: Group A and Group B have different HPR servers specified within the admin portal. However, Group A has outbound connectivity allowed to Group B machines. If a user from Group A connects to a host belonging to Group B, the HPR server specified for Group B will be used. The host machine will always use the config of the group that it belongs to- in this case, the host isn't even aware that the user making the connection belongs to a group 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.