PartySendMessageOptions

Optionen zum Steuern, wie eine Nachricht gesendet wird.

Syntax

enum class PartySendMessageOptions  : int32_t  
{  
    Default = 0x0000,  
    GuaranteedDelivery = 0x0001,  
    BestEffortDelivery = 0x0000,  
    SequentialDelivery = 0x0002,  
    NonsequentialDelivery = 0x0000,  
    CopyDataBuffers = 0x0000,  
    DontCopyDataBuffers = 0x0004,  
    CoalesceOpportunistically = 0x0000,  
    AlwaysCoalesceUntilFlushed = 0x0008,  
    RequireTimelyAcknowledgement = 0x0000,  
    AllowLazyAcknowledgement = 0x0010,  
}  

Konstanten

Konstante	Beschreibung
Standard	Verwenden Sie die Standardeinstellung PartySendMessageOptions. Die Standardoptionen sind BestEffortDelivery, NonsequentialDelivery, CopyDataBuffers, CoalesceOpportunistically und RequireTimelyAcknowledgement.
GuaranteedDelivery	Stellen Sie sicher, dass die Nachricht an alle Ziele übermittelt wird und bei Bedarf erneut übermittelt wird. Dieses Optionsflag garantiert, dass die Nachricht unabhängig vom Verlust von Umgebungspaketen an jedem Zielendpunkt eingeht, es sei denn, der Zielendpunkt wird zerstört. Paketübertragungen werden bei Bedarf wiederholt. 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. Verwenden Sie es mit Nachrichteninhalten, die keine Redundanz oder die Möglichkeit haben, bei Verlust interpoliert/extrapoliert zu werden. Dies ist die potenziell erhöhte Bandbreitennutzung wert, wenn Paketneuübertragungen erforderlich sind. Die Gewährleistung der Lieferung allein bedeutet keine Garantie für einen bestimmten Lieferauftrag; verwenden Sie das Optionsflag SequentialDelivery , um die Reihenfolge zu erzwingen.
BestEffortDelivery	Übertragen Sie die Nachricht nach bestem Aufwand, und ignorieren Sie jeden Paketverlust. Dieses Optionsflag fordert nur einen einzigen Versuch an, die Nachricht zu übertragen. Wenn ein Umgebungspaketverlust auftritt, wird die Übertragung nicht wiederholt, und die Anwendung sollte darauf vorbereitet sein, das Fehlen der Nachricht zu behandeln. Dieses Optionsflag eignet sich gut für Informationen, die ständig aktualisiert werden und nicht jedes Update eintreffen muss. Verwenden Sie sie mit Nachrichteninhalten, die bereits über Redundanz verfügen, oder mit der Möglichkeit, interpoliert/extrapoliert zu werden, wenn sie verloren gehen und keine zusätzliche Bandbreite für die erneute Übertragung wert sind. Dies ist die Standardeinstellung, wenn das Optionsflag GuaranteedDelivery nicht angegeben ist.
SequentialDelivery	Übermitteln Sie die Nachricht relativ zu anderen Nachrichten, die von diesem lokalen Endpunkt gesendet werden, an den Zielendpunkt, die ebenfalls sequenziell gesendet wurden. SequentialDelivery bietet keine Garantien für die Reihenfolge von Nachrichten, die von verschiedenen lokalen Endpunkten und/oder an verschiedene Zielendpunkte gesendet werden. Jede Endpunktpaarung sollte als separater Sequenzbereich betrachtet werden. Es werden keine Garantien für die Reihenfolge sequenzieller Nachrichten in Bezug auf nicht sequenzielle Nachrichten gegeben. Dieses Optionsflag eignet sich gut für Zustandsinformationen, die das Ziel in einer bestimmten Sequenz erreichen sollten, auch wenn dies eine etwas geringere Netzwerkeffizienz bedeutet und möglicherweise etwas länger auf den Empfang wartet, wenn paketverlustend oder neu angeordnet durch die Umgebung erfolgt. Die Verwendung von SequentialDelivery mit GuaranteedDelivery kann dazu führen, dass Nachrichten auf dem Zielendpunkt in die Warteschlange gestellt werden, während sie darauf warten, dass zuvor gesendete sequenzielle Nachrichten eintreffen. Dies kann zu einer wahrgenommenen Erhöhung der Latenz führen, wenn es zu einem Verlust oder einer Neuanordnung von Umgebungspaketen kommt, aber der Zielendpunkt sieht immer jede Nachricht in der gleichen Reihenfolge, in der sie gesendet wurden. Die Verwendung von SequentialDelivery mit BestEffortDelivery kann dazu führen, dass Nachrichten verworfen werden, wenn sie nicht ordnungsgemäß am Zielendpunkt ankommen und eine spätere sequenzielle Nachricht bereits zugestellt wurde. Der Zielendpunkt sieht die Sequenz immer im Weiteren, aber es kann Lücken in dieser Sequenz geben. Eine ältere Nachricht wird nie nach einer neueren Nachricht zugestellt.
NonsequentialDelivery	Übermitteln Sie die Nachricht an Ziele, sobald sie eintrifft. Nachrichten, die mit der Nicht-sequenziellen Übermittlungsoption gesendet werden, bieten keine Garantien hinsichtlich der Reihenfolge, in der sie in Bezug auf andere Nachrichten übermittelt werden, sequenziell oder nicht sequenziell. Sie werden an die Ziele übermittelt, sobald sie eintreffen, was möglicherweise nicht die gleiche Reihenfolge ist, in der sie gesendet wurden, wenn es zu Paketverlusten oder einer Neuanordnung durch die Umgebung kommt. Dieses Optionsflag eignet sich gut für Nachrichten, die sicher in beliebiger Reihenfolge verarbeitet werden können oder bereits über eigene inhärente Bestellinformationen verfügen, und bei denen Sie eine maximale Netzwerkeffizienz und die niedrigste wahrgenommene Latenz wünschen. Dies ist die Standardeinstellung, wenn das Optionsflag SequentialDelivery nicht angegeben ist.
CopyDataBuffers	Weist die Parteibibliothek an, eine Kopie der bereitgestellten Datenpuffer für die nachfolgende Übertragung zu erstellen. Der Speicherinhalt in den bereitgestellten PartyDataBuffer-Strukturen wird kopiert, sodass der Aufrufer die Puffer nach der Rückgabe von PartyLocalEndpoint::SendMessage() nicht beibehalten muss. Dies ist bequemer, aber etwas weniger effizient als die Verwendung des DontCopyDataBuffers-Optionsflags . Dies ist die Standardeinstellung, wenn das DontCopyDataBuffers-Optionsflag nicht angegeben ist.
DontCopyDataBuffers	Informiert die Parteibibliothek, die bereitgestellten Datenpuffer direkt zu verwenden und dass der Aufrufer den Speicher gültig hält, bis die Bibliothek sie nicht mehr benötigt. Der Speicher, auf den von den bereitgestellten PartyDataBuffer-Strukturen verwiesen wird, wird nicht kopiert, sondern der Besitz wird vorübergehend in die Parteibibliothek übertragen, sodass ohne zusätzlichen Kopieraufwand während des Übertragungsprozesses direkt auf den Speicher zugegriffen werden kann. Es liegt in der Verantwortung des Aufrufers sicherzustellen, dass die Speicherpuffer gültig und unverändert bleiben, bis die Bibliothek sie nicht mehr benötigt und der Besitz über ein PartyDataBuffersReturnedStateChange zurücküberwiesen wird. Dies ist effizienter, kann aber weniger praktisch sein als die Verwendung der Option CopyDataBuffers . Die PartyDataBuffer-Strukturen selbst müssen nicht gültig bleiben, nachdem der PartyLocalEndpoint::SendMessage() -Aufruf zurückgegeben wird, nur der Speicher, auf den sie verweisen.
CoalesceOpportunistisch	Gibt an, dass diese Nachricht mit allen anderen Nachrichten in der Warteschlange zusammengefasst werden soll, die Übertragung jedoch nicht verzögert werden soll, wenn keine Warten vorhanden sind. Das Zusammenfügen mehrerer Nachrichten in einem einzelnen Paket ermöglicht die Maximierung der Bandbreiteneffizienz (Reduzierung des Mehraufwands pro Paket) auf potenzielle Kosten der wahrgenommenen Latenz für eine Nachricht, wenn Sie die Übertragung verzögern, um eine Zusammenführung zu erzielen. Das Senden mit diesem Flag bewirkt, dass die Parteibibliothek die Nachricht zusammenfügt, wenn andere Nachrichten in der Warteschlange verfügbar sind, aber nicht auf weitere Nachrichten warten, wenn keine vorhanden sind und diese Nachricht sofort übertragen werden kann. Verwenden Sie dieses Flag, wenn Sie Ihre Netzwerkupdates in der Regel in einzelne, regelmäßige Nachrichten stapeln, die wahrscheinlich nicht zur gleichen Zeit wie andere Nachrichten in die Warteschlange eingereiht werden und bei einer Verzögerung keine Bandbreiteneffizienz erzielen würden. Dieses Flag garantiert nicht, dass die Nachricht sofort gesendet wird. Wenn die Verbindungsqualität oder die Empfängerreaktionsfähigkeit derzeit das Senden zusätzlicher Daten noch nicht unterstützt, wird die Nachricht möglicherweise in die Warteschlange gestellt, um auf die nächste Übertragungschance zu warten. Dies ist die Standardeinstellung, wenn das Optionsflag AlwaysCoalesceUntilFlushed nicht angegeben ist.
AlwaysCoalesceUntilFlushed	Gibt an, dass diese Nachricht immer versuchen soll, mit anderen Nachrichten zusammenzuschließen und zu erwarten, dass ein PartyLocalEndpoint::FlushMessages() -Aufruf mit der Übertragung beginnt. Das Zusammenfügen mehrerer Nachrichten in einem einzelnen Paket ermöglicht die Maximierung der Bandbreiteneffizienz (Reduzierung des Mehraufwands pro Paket) auf potenzielle Kosten der wahrgenommenen Latenz für eine Nachricht, wenn Sie die Übertragung verzögern, um eine Zusammenführung zu erzielen. Das Senden mit diesem Flag bewirkt, dass die Parteibibliothek immer das Zusammenfügen der Nachricht vorzieht und die Übertragung verzögert, bis PartyLocalEndpoint::FlushMessages() aufgerufen wird. Erwägen Sie die Verwendung dieses Flags, wenn Sie in der Regel viele kleine Nachrichten an dieselben Ziele in derselben Updateschleife senden und die Party-Bibliothek explizit darüber informieren möchten, wenn die vollständige Iteration der Updateschleife abgeschlossen ist. Selbst mit diesem Flag gibt es Szenarien, in denen die Nachricht mit der Übertragung beginnen kann, ohne dass ein expliziter Aufruf von PartyLocalEndpoint::FlushMessages() erforderlich ist. Dies kann auftreten, wenn andere Nachrichten in der Warteschlange vorhanden sind, die bereits aus anderen Gründen übertragen werden und im Paket Platz für die Aufnahme dieser Nachricht vorhanden ist. Wenn genügend Nachrichtendatenbytes vorhanden sind, um ein vollständiges Paket zu senden, und keine weitere Zusammenführung möglich ist, wird das Paket gesendet. Das Aufrufen von PartyLocalEndpoint::FlushMessages(), wenn alle Nachrichten bereits mit der Übertragung begonnen haben, ist harmlos.
RequireTimelyAcknowledgement	Gibt an, dass diese Nachricht (falls erforderlich) rechtzeitig bestätigt werden soll. Empfänger bestätigen den Empfang von Nachrichten, um den Absender über erfolgreiche oder fehlgeschlagene Übermittlungen zu informieren, damit er beispielsweise verworfene Pakete wiederholen kann, die Nachrichten enthielten, die mit dem Optionsflag GuaranteedDelivery gesendet wurden. Bestätigungen werden häufig als Teil der typischen bidirektionalen Kommunikation für Pakete huckepackt. Wenn jedoch keine Pakete in der Rückgaberichtung fließen, weist dieses Flag die Zielendpunkte an, nur ein kleines, intern verwaltetes Timeout für Piggybacking-Möglichkeiten zu warten, bevor Bestätigungspakete erzwungen werden, um den Absender zu informieren. Dieses dedizierte Paket verursacht einen zusätzlichen Mehraufwand, stellt aber sicher, dass der Absender rechtzeitig status erhält, um alle erforderlichen Wiederholungen auszustellen. Die Verwendung dieses Flags für die meisten garantierten Übermittlungsnachrichten wird empfohlen. Dies funktioniert gut mit Nachrichten, die latenzempfindlich sind. Dies funktioniert auch gut, wenn bidirektionale garantierte Sendemuster selten oder unvorhersehbar sind. Dies ist die Standardeinstellung, wenn das Optionsflag AllowLazyAcknowledgement nicht angegeben ist. Dieses Flag wird ignoriert, wenn das Optionsflag GuaranteedDelivery nicht angegeben ist.
AllowLazyAcknowledgement	Gibt an, dass diese Nachricht bei Bedarf und nicht dringend bestätigt werden kann. Empfänger bestätigen den Empfang von Nachrichten, um den Absender über erfolgreiche oder fehlgeschlagene Übermittlungen zu informieren, damit er beispielsweise verworfene Pakete wiederholen kann, die Nachrichten enthielten, die mit dem Optionsflag GuaranteedDelivery gesendet wurden. Bestätigungen werden häufig als Teil der typischen bidirektionalen Kommunikation für Pakete huckepackt, aber wenn keine Pakete in der Rückgaberichtung fließen, weist dieses Flag die Zielendpunkte an, auf Piggybacking-Möglichkeiten zu warten, ohne Bestätigungspakete zu zwingen, den Absender zu informieren. Dadurch wird der Absender verzögert, status für alle erforderlichen Wiederholungen herauszufinden, aber es wird ein zusätzlicher Mehraufwand vermieden, der durch ein dediziertes Paket beansprucht wird. Erwägen Sie die Verwendung dieses Flags für garantierte Übermittlungsnachrichten, die "fire-and-forget" sind und nicht latenzempfindlich sind. Es kann auch den Mehraufwand reduzieren, wenn bidirektionale Sendemuster häufig sind. Dieses Flag wird ignoriert, wenn das Optionsflag GuaranteedDelivery nicht ebenfalls angegeben ist.

Voraussetzungen

Header: Party.h

Weitere Informationen

Party-Mitglieder
PartySendMessageQueuingConfiguration
PartyDataBuffersReturnedStateChange
PartyLocalEndpoint::SendMessage
PartyLocalEndpoint::FlushMessages