PlayFab Party und direkte Peer-to-Peer-Verbindungen

Auf dieser Seite wird erläutert, wie Sie direkte Peer-to-Peer-Verbindungen in playFab Party mithilfe von Beispielspielcode aktivieren und verwenden können. Es enthält auch Überlegungen, die Ihnen helfen, zu bewerten, wann direkte Peer-to-Peer-Verbindungen in Ihren Spielen verwendet werden sollen.

Wann sollte direkte Peer-to-Peer-Verbindungen verwendet werden?

PlayFab Party unterstützt eine Vielzahl von Kommunikationstopologien. Konzeptionell werden alle Chat- oder Datennachrichten von einem Peergerät oder Benutzer direkt an andere gesendet. Die Partei nutzt jedoch automatisch einen transparenten Cloudrelaydienst, um häufige Umgebungs- und Sicherheitsprobleme beim Einrichten direkter Peer-to-Peer-Verbindungen zu vermeiden. Sie können die Datenübertragung mit geringer Latenz erreichen, indem Sie die QoS-Messungen (QoS) im Hintergrund nutzen. (Weitere Informationen finden Sie unter QoS-Messungen für PlayFab-Party.) Sie können optional direkte Peer-to-Peer-Verbindungen aktivieren, um die Datenübertragungslatenz weiter zu reduzieren. Aufgrund von Sicherheitsbedenken, die unter "Sicherheitsüberlegungen" unten beschrieben werden, empfiehlt Microsoft, dass Sie unseren Cloudrelaydienst verwenden, anstatt eine direkte Peer-zu-Peer-Verbindung zu aktivieren, es sei denn, Ihr Titel hat strenge Latenzanforderungen.

Plattformunterstützung

Direkte Peerkonnektivität wird in den Windows 10-, Microsoft Game Core-, Nintendo Switch-, PlayStation®4- und PlayStation®5-Versionen der Party-Bibliothek unterstützt. Andere Versionen der Bibliothek verwenden immer das Cloudrelay für die Datenübertragung, unabhängig von den direkten Peerkonnektivitätsoptionen, die über die Client-API angegeben werden.

"PlayStation" ist eine eingetragene Marke oder Marke von Sony Interactive Entertainment Inc.

Sicherheitsfragen

Da direkte Peerkonnektivität verwendet wird, um Daten direkt zwischen Clients zu senden, müssen alle Clients wissen, wie sie eine Verbindung miteinander herstellen. Dies erfolgt durch gemeinsames Freigeben von Client-IP-Adressen zwischen Clients in einer Spielsitzung. Wenn beispielsweise ein Multiplayer-Spiel mit 16 Spielern direkte Peerkonnektivität zum Aktualisieren der Spielerpositionen verwendet, muss jeder der 16 Spielclients die IP-Adressen der 15 anderen Clients kennen, um zu wissen, an wen Daten gesendet werden sollen.

Die gemeinsame Nutzung von IP-Adressen zwischen Spielclients ist ein Sicherheitsrisiko. Die Freigabe von IP-Adressen kann es böswilligen Akteuren ermöglichen, die IP-Adresse zu erkennen und sie zu verwenden, um andere Spieler außerhalb von Spielen böswillig anzugreifen. Eine gängige Methode zum Durchführen dieser Angriffe durch Dos-Angriffe (Denial-of-Service) oder eine Variante namens Distributed Denial of Service (DDOS)-Angriffe. Die Angriffe funktionieren, indem versucht wird, ein Netzwerk mit überflüssigem Netzwerkdatenverkehr zu überlasten. Wenn ein Angreifer genügend Netzwerkdatenverkehr an sein Opfer senden kann, muss die Netzwerkhardware des Opfers (Modem und Router) seine ganze Zeit damit verbringen, den überflüssigen Datenverkehr zu verarbeiten, und hat keine Zeit, seine normalen Aufgaben zur Verarbeitung legitimer Netzwerkverbindungen zu erledigen. Effektiv bedeutet dies, dass das Opfer sein Netzwerk nicht für die gesamte Dauer des Angriffs nutzen kann. Dies wird häufig als "offline gestartet" bezeichnet.

Abschließend kann eine erfolgreiche direkte Peerkonnektivität zu einer geringeren Latenz zwischen einigen Geräten führen. Der Versuch, es einzurichten, erfordert jedoch auch, dass Benutzer ihre IP-Adressen an andere weitergeben, was es böswilligen Benutzern ermöglichen kann, ihre Geräte und Internetverbindungen außerhalb des Titels anzugreifen. Direkte Peerverbindungen sind möglicherweise auch auf bestimmten Plattformen aus Richtliniengründen nicht zulässig. Stellen Sie sicher, dass Sie die geeigneten Optionen für direkte Peerkonnektivität für Ihre Leistungs- und Sicherheitsziele verwenden. Wenn Sie sich nach dem Abwägen der Risiken für die Verwendung der direkten Peerkonnektivität entscheiden, verwenden Sie die folgenden Beispiele, um Ihren Titel auf Netzwerk- und Gerätebasis zu aktivieren.

LAN-Szenarien

Direkte Peerkonnektivität in Party kann verwendet werden, um extrem niedrige Latenz in LAN-Szenarien zu ermöglichen. Selbst in diesen Szenarien ist jedoch eine eingeschränkte Internetkonnektivität erforderlich, um die Benutzerauthentifizierung, LiveOps-Daten und -Erkenntnisse sowie Barrierefreiheitsfeatures für Sprachchats zu unterstützen.

Überlegungen zur Upstreambandbreite

Die Verwendung direkter Peer-to-Peer-Konnektivität kann die Upstream Bandbreitennutzung Ihres Spiels erhöhen. Beim Übertragen eines Spiels oder einer Sprachnachricht über den Cloudrelaydienst sendet party eine einzelne Nachricht an den Dienst; Der Dienst repliziert dann die Nachricht und leitet sie an jedes Zielgerät weiter. Bei der Übertragung eines Spiels oder einer Sprachnachricht über direkte Peer-to-Peer-Verbindungen repliziert und sendet party die Nachricht über eine direkte Verbindung für jedes Zielgerät, mit dem eine direkte Peer-zu-Peer-Verbindung hergestellt wurde. Daher wird die Upstream Bandbreitennutzung Ihres Spiels proportional zur Anzahl der Geräte skaliert, mit denen eine direkte Peer-to-Peer-Verbindung hergestellt wurde. Überlegen Sie, ob diese Erhöhung der Upstream Bandbreite für Ihr Spiel akzeptabel ist, bevor Sie direkte Peer-to-Peer-Verbindungen aktivieren.

Verwenden direkter Peer-to-Peer-Verbindungen in Ihrem Spiel

Aktivieren direkter Peer-to-Peer-Verbindungen in Ihrem Netzwerk

Beim Erstellen eines Netzwerks über PartyManager::CreateNewNetwork()können Sie verschiedene Netzwerkkonfigurationsparameter über die PartyNetworkConfiguration für den Aufruf bereitgestellte angeben. Sie können das PartyNetworkConfiguration::directPeerConnectivityOptions Feld verwenden, um anzugeben, ob und wie direkte Peer-to-Peer-Verbindungen für Geräte im Netzwerk unterstützt werden.

Das folgende Beispiel zeigt eine Netzwerkkonfiguration, die angibt, dass direkte Peer-to-Peer-Verbindungen zwischen allen Geräten im Netzwerk versucht werden sollen, unabhängig vom Plattformtyp oder Anmeldeanbieter.

PartyNetworkConfiguration configuration = {};
configuration.directPeerConnectivityOptions = PartyDirectPeerConnectivityOptions::AnyPlatformType | PartyDirectPeerConnectivityOptions::AnyEntityLoginProvider;
// Initialize the rest of the network configuration parameters appropriately for your game before using.

Im Rahmen der erfolgreichen Authentifizierung eines ersten Benutzers in einem Netzwerk kann ein Gerät versuchen, direkte Peer-to-Peer-Verbindungen mit anderen Geräten herzustellen, die bereits am Netzwerk beteiligt sind, sofern dies durch die Netzwerkkonfiguration zulässig ist. Bei erfolgreichen Versuchen werden Endpunktnachrichten und Chatdaten zwischen den Geräten mithilfe dieser direkten Verbindungen übertragen. Bei Versuchen, die aufgrund von Umgebungsinkompatibilitäten zwischen den Geräten fehlschlagen, wird die gesamte Kommunikation zwischen diesen Geräten stattdessen über transparente Cloudrelayserver übertragen. Wenn die Geräte keine direkten Peerverbindungen über die Netzwerkkonfiguration versuchen dürfen, tauschen sie niemals IP-Adressinformationen aus und übertragen immer Endpunktnachrichten und Chatdaten über transparente Cloudrelayserver.

Notiz

Das Einrichten direkter Peerkonnektivität ist die beste Vorgehensweise und aufgrund von Umgebungsfaktoren, Gerätekonnektivitätsoptionen oder Plattformrichtlinien möglicherweise nicht möglich. Weitere Informationen zum Bewerten, ob eine direkte Peer-zu-Peer-Verbindung mit einem bestimmten Gerät hergestellt wurde, finden Sie unter Auswerten des Verbindungstyps und der Latenz.

Einschränken der direkten Peerkonnektivität pro Gerät

Neben den Direkten Peerkonnektivitätsoptionen in der Netzwerkkonfiguration kann die direkte Peerkonnektivität durch ein Gerät für alle Netzwerke, bei denen es sich authentifiziert, weiter eingeschränkt werden, indem verwendet PartyManager::SetOption() wird, um festzulegen PartyOption::LocalDeviceDirectPeerConnectivityOptionsMask. Alle Flags werden mithilfe einer bitweisen AND-Operation ausgewertet. Das heißt, ein bestimmtes Flag ist nur für das Gerätepaar eines bestimmten Netzwerks wirksam, wenn es an drei Stellen aktiviert ist: der Netzwerkkonfiguration und den jeweiligen lokalen Maskenoptionen beider Geräte. Selbst wenn die Netzwerkkonfiguration eine direkte Peerkonnektivität in der relevanten Form zulässt, kann beide Geräte unabhängig von der Offenlegung der IP-Adresse und direkten Verbindungsversuchen zwischen ihnen abwählen, indem das Flag in seiner lokalen Gerätemaskenoption nicht aktiviert wird. In Versionen der Bibliothek, die direkte Peerkonnektivität unterstützen, ist der PartyOption::LocalDeviceDirectPeerConnectivityOptionsMask Wert standardmäßig auf alle von Netzwerken aktivierten direkten Peerverbindungen zulässig. Daher müssen Sie sie nur konfigurieren, wenn gerätespezifische Anforderungen vorliegen, um eine direkte Peerkonnektivität mit dem lokalen Gerät zu verhindern.

Das folgende Beispiel zeigt, wie Die direkte Peerkonnektivität für das lokale Gerät eingeschränkt wird, sodass nur versucht wird, eine direkte Peerkonnektivität mit Geräten derselben Plattform herzustellen.

PartyDirectPeerConnectivityOptions localDeviceMask = PartyDirectPeerConnectivityOptions::SamePlatformType | PartyDirectPeerConnectivityOptions::AnyEntityLoginProvider;
PartyError error = PartyManager::GetSingleton().SetOption(nullptr, PartyOption::LocalDeviceDirectPeerConnectivityOptionsMask, &localDeviceMask);
if (PARTY_FAILED(error))
{
    printf("Failed to set local device direct peer connectivity options mask! error = 0x%08x\n", error);
}

Auswerten des Verbindungstyps und der Latenz

Sie können ermitteln, ob das lokale Gerät eine direkte Peer-zu-Peer-Verbindung mit einem bestimmten Remotegerät hergestellt hat, indem Sie aufrufen PartyNetwork::GetDeviceConnectionType().

Es wird empfohlen, die Verfügbarkeit einer direkten Peer-zu-Peer-Verbindung für ein bestimmtes Gerätepaar nicht aktiv zu erzwingen (d. h. nicht aufrufen PartyNetwork::LeaveNetwork() , wenn PartyNetwork::GetDeviceConnectionType() einen anderen Wert als PartyDeviceConnectionType::DirectPeerConnectionmeldet, da die spezifische zugrunde liegende Übertragungsmethode die gesamte logische Kommunikationsfähigkeit nicht ändert. Wenn Ihr Spielentwurf strenge Anforderungen an die maximale Nachrichtenlatenz hat, die direkte Peerkonnektivität fördern, ist es besser, maßnahmen auf die aktuellen konkreten Beobachtungen dieser Latenz zu treffen, wie von der PartyEndpointStatistic::AverageDeviceRoundTripLatencyInMilliseconds Statistik gemeldet, anstatt abstrakte Annahmen basierend auf dem Übertragungsmechanismus zu treffen. Andernfalls könnten Sie Benutzer ständig daran hindern, mit derselben Gruppe von Freunden zu spielen, die immer in der Nähe befindliche transparente Cloudrelayserver verwenden müssen, da umgebungsbedingte Faktoren außerhalb ihrer Kontrolle liegen.

Das folgende Beispiel zeigt, wie die Roundtriplatenz von einem localEndpoint zu einem remoteEndpoint in einem networküberprüft wird.

// A helper for inspecting the connection type and average round trip latency between a local endpoint and a remote
// endpoint in a network.
void PrintConnectionTypeAndLatency(
    PartyNetwork* network,
    PartyLocalEndpoint* localEndpoint,
    PartyEndpoint* remoteEndpoint
    )
{
    // Retrieve the device associated with the remote endpoint.
    PartyDevice* remoteDevice;
    PartyError error = remoteEndpoint->GetDevice(&remoteDevice);
    if (PARTY_FAILED(error))
    {
        printf("Failed to get the remote device! error = 0x%08x\n", error);
        return;
    }

    // Get the device connection type.
    PartyDeviceConnectionType connectionType;
    PartyError error = network->GetDeviceConnectionType(remoteDevice, &connectionType);
    if (PARTY_FAILED(error))
    {
        printf("Failed to get device connection type! error = 0x%08x\n", error);
        return;
    }

    // Retrieve the latency statistic.
    PartyEndpointStatistic latencyStatistic = PartyEndpointStatistic::AverageDeviceRoundTripLatencyInMilliseconds;
    uint64_t latencyStatisticValue;
    error = localEndpoint->GetEndpointStatistics(
        1,                       // targetEndpointCount
        &remoteEndpoint,         // targetEndpoints
        1,                       // statisticCount
        &latencyStatistic,       // statisticTypes
        &latencyStatisticValue); // statisticValues
    if (PARTY_FAILED(error))
    {
        printf("Failed to get latency statistic! error = 0x%08x\n", error);
        return;
    }

    // Print the results.
    printf("Local endpoint 0x%p and remote endpoint 0x%p in network 0x%p have average round trip latency %llu ms and device connection type %i\n",
        localEndpoint,
        remoteEndpoint,
        network,
        latencyStatisticValue,
        static_cast<int32_t>(connectionType));
}

Änderungen am Verbindungstyp

Es ist möglich, dass sich ändernde Umgebungsbedingungen eine direkte Peerverbindung stören können, sodass sie für PlayFab Party unbrauchbar wird. In diesem Fall versuchen die Geräte, auf die Kommunikation über den Cloudrelayserver zurückzugreifen. Wenn eine relayfähige Kommunikation weiterhin möglich ist, beginnt die Funktion PartyNetwork::GetDeviceConnectionType() mit der Meldung von PartyDeviceConnectionType::RelayServer , und die Geräte verbleiben in Zukunft im Netzwerk der Partei mit dem neuen Verbindungstyp. Andernfalls verlassen die Geräte mit unterbrochener Konnektivität das Netzwerk.

Warnung

Chat- und Spielnachrichten, die sich noch während der Übertragung oder des Empfangens auf der direkten Peerverbindung befanden, als sie unterbrochen wurde, gehen möglicherweise nie ein. auch dann, wenn sie mit PartySendMessageOptions::GuaranteedDelivery gesendet wurden, und auch wenn sie nicht mehr in den PartyEndpointStatistic::CurrentlyQueuedSendMessages - oder PartyEndpointStatistic::CurrentlyActiveSendMessages-Werten gezählt werden, die von PartyLocalEndpoint::GetEndpointStatistics() zurückgegeben werden. Darüber hinaus können Nachrichten, die während des Übergangszeitraums des Verbindungstyps übertragen wurden, nicht in der richtigen Reihenfolge eintreffen, selbst wenn sie mit PartySendMessageOptions::SequentialDelivery gesendet wurden. Ihr Titel sollte auf diese Möglichkeit von Datenverlust und Fehlordnung bei Verwendung von direkten Peerverbindungen und diesen PartySendMessageOptions vorbereitet sein.

Der Verbindungstyp PartyDeviceConnectionType::RelayServer wird niemals in einen anderen Typ geändert, unabhängig davon, ob dieser Wert zugewiesen wurde, als das Gerät zum ersten Mal dem Netzwerk beigetreten war oder nachdem eine zuvor unterbrochene direkte Peerverbindung aufgetreten war.

Abrechnungszähler

Die gleichen Abrechnungszähler werden in Netzwerken angewendet, die direkte Peer-to-Peer-Verbindungen verwenden, wie in Netzwerken, die den Cloudrelaydienst verwenden. Allerdings werden nur Spiel- oder Sprachdaten, die den Cloudrelaydienst durchlaufen, auf die Sprachzähler für Netzwerkausgang und Party gezählt.