PartyDirectPeerConnectivityOptions

Flags controlling the attempted use of direct peer-to-peer connectivity among devices in a network.

Syntax

enum class PartyDirectPeerConnectivityOptions  : int32_t  
{  
    None = 0x0,  
    SamePlatformType = 0x1,  
    DifferentPlatformType = 0x2,  
    AnyPlatformType = SamePlatformType | DifferentPlatformType,  
    SameEntityLoginProvider = 0x4,  
    DifferentEntityLoginProvider = 0x8,  
    AnyEntityLoginProvider = SameEntityLoginProvider | DifferentEntityLoginProvider,  
    OnlyServers = 0x10,  
}  

Constants

Remarks

As part of successfully authenticating an initial user into a network, a device may attempt to establish direct peer-to-peer connections with other devices already participating in the network when permitted by these flags declared in the network's PartyNetworkConfiguration structure. For attempts that are successful, endpoint messages and chat data between the devices will be transmitted using those direct connections. For attempts that fail due to environmental incompatibilities between the devices, all communication between those devices will be transmitted via transparent cloud relay servers instead. If the devices aren't permitted to attempt direct peer connections by these flags, then they never exchange IP address information and will always transmit endpoint messages and chat data via transparent cloud relay servers.

You can determine whether the local device actually established a direct peer-to-peer connection to a specific remote device by calling PartyNetwork::GetDeviceConnectionType().

Successful direct peer connectivity may provide lower latency between some devices, though attempting to establish it also requires users to disclose their devices' IP addresses to others, which may be a concern for privacy or for enabling malicious users to potentially attack peers' devices and Internet connections outside of the title. It also may not be permitted on certain platforms for policy reasons. Be sure to use the appropriate flags for your performance and security goals.

Besides a specific network's PartyNetworkConfiguration::directPeerConnectivityOptions value, the flags may optionally be further constrained by a device for all networks into which it authenticates by using PartyManager::SetOption() to set PartyOption::LocalDeviceDirectPeerConnectivityOptionsMask. All flags are evaluated using a bitwise AND operation. That is, a particular flag is only in effect for a given network's pair of devices if it's enabled in three places: the network's PartyNetworkConfiguration structure, and both devices' respective local mask options. Even if the Party network permits direct peer connectivity of the relevant form, either device can unilaterally opt out of the IP address disclosure and direct connection attempts between them by not enabling the flag. The PartyOption::LocalDeviceDirectPeerConnectivityOptionsMask value defaults to permitting all direct peer connections enabled by networks, so you only need to configure it if you have device-specific requirements to prevent some or all direct peer connectivity involving it.

To avoid excessive resource consumption, the Party library will also internally prevent any given device from attempting to establish more than a configured maximum number of direct peer connections across all networks in which it's currently participating, even if permitted by these flags. This doesn't affect the device's ability to participate in large or multiple networks with more remote devices. Communication with extra devices will simply be transmitted via transparent cloud relay servers. To modify that maximum number of direct peer connections, use PartyManager::SetOption() to set PartyOption::LocalDeviceMaxDirectPeerConnections.

It's recommended that you don't actively enforce the availability of a direct peer-to-peer connection for any given pair of devices (that is, don't call PartyNetwork::LeaveNetwork() if PartyNetwork::GetDeviceConnectionType() reports a value other than PartyDeviceConnectionType::DirectPeerConnection) since the specific underlying transmission method in use doesn't alter the overall logical ability to communicate. If your game design has stringent requirements for maximum message latency that encourage direct peer connectivity, it's better to take action on the current concrete observations of that latency as reported by the PartyEndpointStatistic::AverageDeviceRoundTripLatencyInMilliseconds statistic rather than make abstract assumptions based on transmission mechanism. Otherwise you might continually hinder users trying to play with the same set of friends who always need to use nearby transparent cloud relay servers due to environmental factors beyond their control.

Requirements

Header: Party.h

See also

Party members
PartyNetworkConfiguration
PartyOption::LocalDeviceDirectPeerConnectivityOptionsMask
PartyManager::SetOption
PartyEndpointStatistic::AverageDeviceRoundTripLatencyInMilliseconds
PartyLocalEndpoint::GetEndpointStatistics