Konfigurieren des Transportverhaltens

Die Netzwerkfunktionen von PlayFab Party erweitern die UDP-Features (User Datagram Protocol) der nativen Plattform, um Datagrammtransportfunktionen bereitzustellen, die ideal für Echtzeit-Multiplayer-Spiele sind.

Während TCP (Transmission Control Protocol) zuverlässige Datenströme bereitstellt und UDP unzuverlässige Datagramme bereitstellt, können Sie das Netzwerkverhalten der Partei pro Datagramm konfigurieren. Wenn Sie PartyLocalEndpoint::SendMessage verwenden, um ein Datagramm von einem lokalen Parteiendpunkt an einen Remoteendpunkt zu übertragen, geben Sie PartySendMessageOptions an, um das gewünschte Transportverhalten zu optimieren.

Zu den Funktionen gehören:

  • Garantierte Zustellung: Das GuaranteedDelivery Flag stellt sicher, dass die Nachricht an allen Zielen ankommt und daten ggf. implizit erneut übertragen werden, um den Verlust von Umgebungspaketen zu minimieren. Dieses Optionsflag funktioniert gut, wenn wichtige Zustandsinformationen gesendet werden, die immer das Ziel erreichen müssen, andernfalls sollte das Ziel aus dem Netzwerk entfernt werden. Die Standardoption ist BestEffortDelivery, die UDP-ähnliches Fire-and-Forget-Verhalten bereitstellt.
  • Sequenzielle Zustellung: Sortiert die Übermittlung der Nachricht relativ zu anderen Nachrichten, die sequenziell von diesem lokalen Endpunkt an den Zielendpunkt gesendet werden. Verwenden Sie dieses Optionsflag, um Zustandsinformationen zu senden, die das Ziel in einer bestimmten Sequenz erreichen müssen. Die sequenzielle Übermittlung kann zu einer etwas geringeren Netzwerkeffizienz und zu einer längeren Wartezeit auf den Empfang aller Pakete führen, wenn paketverlustend oder neu angeordnet wird. Die Verwendung von SequentialDelivery mit GuaranteedDelivery kann dazu führen, dass Nachrichten auf dem Zielendpunkt in die Warteschlange gestellt werden, während auf zuvor gesendete sequenzielle Nachrichten gewartet wird. Warteschlangen können die wahrgenommene Latenz während des Verlusts oder der Neuanordnung von Umgebungspaketen erhöhen, aber der Zielendpunkt sieht immer jede Nachricht in der gesendeten Reihenfolge. Dieser Leistungsabtausch ist bei TCP-ähnlichen Protokollen üblich und wird manchmal als Head-of-Line-Blockierung bezeichnet.
  • Sammelvorgang: Die Parteibibliothek fragmentiert und zusammengesetzt automatisch große Nachrichten, die die maximale Größe überschreiten, die von der Umgebung unterstützt wird, sodass Aufrufer die Fragmentierung nicht verwalten müssen. Wenn Sie viele kleine Datagramme senden, kombiniert das Zusammenführen diese zu einem einzelnen Paket, um die Bandbreiteneffizienz zu verbessern und die potenziellen Kosten einer zusätzlichen Latenz zu erhöhen. Durch das Senden mit dem CoalesceOpportunistically Flag (Standard) wird die Nachricht mit anderen Nachrichten in der Warteschlange zusammengefasst, sofern diese verfügbar sind, wartet jedoch nicht auf weitere Nachrichten, wenn die Nachricht sofort übertragen werden kann. Das Senden mit dem Flag verzögert die AlwaysCoalesceUntilFlushed Übertragung, bis PartyLocalEndpoint::FlushMessages aufgerufen wird. An diesem Punkt werden Nachrichten in der Warteschlange zusammengefasst und übertragen.

Party-Transportoptionen

Kombinieren von Übermittlungs- und Sequenzierungsoptionen

Die GuaranteedDelivery/BestEffortDelivery Optionen und SequentialDelivery/NonsequentialDelivery sind unabhängig und können frei kombiniert werden. Jede Kombination erzeugt ein eindeutiges Verhalten:

Zustellung Sequenzierung Verhalten
GuaranteedDelivery SequentialDelivery Zuverlässig und geordnet. Jede Nachricht kommt in der gesendeten Reihenfolge an. Wenn eine Nachricht während der Übertragung verloren geht, werden spätere sequenzielle Nachrichten auf dem Empfänger in die Warteschlange eingereiht, bis die fehlende Nachricht erneut übertragen und übermittelt wird. Am anfälligsten für Head-of-Line-Blockierungen.
GuaranteedDelivery NonsequentialDelivery Zuverlässig und ungeordnet. Jede Nachricht kommt ein, aber jede wird an die Anwendung übermittelt, sobald sie eingeht, unabhängig von der Sendereihenfolge. Keine Kopfzeilenblockierung.
BestEffortDelivery SequentialDelivery Unzuverlässig und bestellt. Nachrichten werden in der richtigen Reihenfolge zugestellt, aber Lücken sind zulässig. Wenn eine Nachricht eingeht, nachdem eine spätere sequenzielle Nachricht bereits zugestellt wurde, wird die eingangsverzögerte Nachricht verworfen. Die Sequenz wird immer vorwärts verschoben.
BestEffortDelivery NonsequentialDelivery Unzuverlässig und ungeordnet (Standard). Feuer und Vergessen – jede Nachricht wird ohne Bestell- oder Liefergarantien übermittelt, sobald sie eingeht. Niedrigste Latenz.

Grundlegendes zur Blockierung von Kopfzeilen

Head-of-Line-Blockierung tritt auf, wenn eine Nachricht am Anfang einer Übermittlungssequenz noch nicht verfügbar ist. Spätere Nachrichten in derselben Sequenz können nicht an die Anwendung übermittelt werden, obwohl sie bereits auf dem Empfänger vorhanden sind.

Die relevante Option für head-of-line-Blockierung ist SequentialDelivery, nicht GuaranteedDelivery. Bei der sequenziellen Übermittlung wird eine geordnete Sequenz erstellt, bei der frühere Nachrichten spätere Nachrichten blockieren. GuaranteedDelivery kann die Auswirkungen übertreiben , da eine fehlende Nachricht erneut übertragen werden muss, anstatt übersprungen zu werden, wodurch die Wartezeit verlängert wird. Mit BestEffortDelivery + SequentialDeliverywird eine Lücke übersprungen, und die Sequenz wird vorwärts verschoben, sodass das blockierende Fenster kurz ist.

NonsequentialDelivery Nachrichten werden nie durch sequenzielle Nachrichten blockiert. Die beiden Übermittlungsmodi stören sich nicht. Eine garantierte sequenzielle Nachricht verzögert nicht die Zustellung einer nicht sequenziellen Nachricht.

Praktische Anleitung

Ein gängiges Spielmuster verwendet mehrere Sendeoptionen gleichzeitig für verschiedene Arten von Daten:

  • GuaranteedDelivery + SequentialDelivery für Spielzustandsänderungen, bei denen Reihenfolge und Vollständigkeit von Bedeutung sind (z. B. Bestandsaktualisierungen, Übereinstimmungszustandsübergänge).
  • BestEffortDelivery + NonsequentialDelivery für schnell veränderliche Zustände, in denen niedrige Latenz mehr zählt als die Vollständigkeit (z. B. Spielerpositionen, Zielrichtung).

Da sequenzielle und nicht sequenzielle Nachrichten unabhängig sind, verzögert eine neu übertragende Zustandsänderungsnachricht die Übermittlung von Positionsaktualisierungen nicht.

Mehrere unabhängige Sequenzen

Jeder lokale Endpunkt stellt einen unabhängigen Sequenzbereich dar. Alle sequenziellen Nachrichten, die von einem lokalen Endpunkt an einen bestimmten Zielendpunkt gesendet werden, haben die gleichen Sortiergarantien. Head-of-Line-Blockierung innerhalb dieser Sequenz kann sich nur auf andere sequenzielle Nachrichten in derselben Sequenz auswirken.

Wenn Sie mehrere unabhängige geordnete Datenströme zwischen denselben beiden Geräten benötigen, z. B. einen Stream pro Spielsubsystem, können Sie mehrere lokale Endpunkte auf jedem Gerät erstellen (bis zu dem in PartyNetworkConfiguration.maxEndpointsPerDeviceCount beim Erstellen des Partynetzwerks angegebenen Grenzwert). Sequenzielle Nachrichten, die von verschiedenen lokalen Endpunkten gesendet werden, haben keine Reihenfolge oder Übermittlungsbeziehung zueinander.

Netzwerkstatistiken und lokale Warteschlangen

Abhängig von den Optionen zum Senden von Nachrichten und dem Netzwerkstatus kann der Partei Nachrichten vor der Übertragung lokal in die Warteschlange stellen. Diese lokale Warteschlange wird sorgfältig verwaltet, um die Einführung von Latenz zu vermeiden. Eine Warteschlange ist erforderlich, um sicherzustellen, dass party nicht das Netzwerk des Spielers überflutet und Features wie Das Zusammenfügen angewendet werden können.

PartyNetwork::GetNetworkStatistics sammelt Daten zur aggregierten Netzwerkleistung, einschließlich der Latenz für den Party relay-Dienst.

PartyLocalEndpoint::GetEndpointStatistics bietet Einblick in Warteschlangen- und Paketverluststatistiken für einen bestimmten Remoteendpunkt.

  • Last updated on