配置传输行为
PlayFab Party 的网络功能在原生平台的用户数据报协议 (UDP) 特性之上进行扩展，提供了非常适合实时多人游戏的数据报传输能力。 传输控制协议 (TCP) 提供可靠流，UDP 提供不可靠数据报；而 Party 允许你按数据报级别配置网络行为。当你使用 PartyLocalEndpoint::SendMessage 从本地 Party 端点向远程端点发送数据报时，可以指定 PartySendMessageOptions 来精细调整所需的传输行为。 功能包括：- 保证送达：
GuaranteedDelivery标志确保消息送达所有目标，必要时会隐式重传数据以缓解环境性丢包。当发送必须始终到达目标（否则应从网络中移除该目标）的重要状态信息时，此标志非常适用。默认选项为BestEffortDelivery，其提供类似 UDP 的”发送后即忘”行为。 - 顺序送达：相对于从本地端点顺序发送到目标端点的其他消息，对消息的送达顺序进行排序。使用此标志可发送必须按特定顺序到达目标的状态信息。顺序送达可能导致网络效率略降，并在环境发生丢包或乱序时增加接收所有数据包的等待时间。将
SequentialDelivery与GuaranteedDelivery一起使用时，消息可能会在目标端点排队等待此前发送的顺序消息到达。排队可能会在环境丢包或乱序时增加感知延迟，但目标端点始终按发送顺序看到每条消息。这种性能取舍在类 TCP 协议中较常见，有时称为 队头阻塞。 - 合并：Party 库会自动对超出环境所支持最大大小的大消息进行分片和重组，因此调用方无需管理分片。若你要发送许多小数据报，合并会将它们组合到单个数据包中，以提升带宽效率，代价是可能增加延迟。使用
CoalesceOpportunistically标志（默认值）发送时，会在有其他排队消息时与之合并，但如果消息可立即发送则不会等待更多消息。使用AlwaysCoalesceUntilFlushed标志发送时，会延迟传输直到调用PartyLocalEndpoint::FlushMessages，此时排队的消息会被合并并传输。
组合送达与顺序选项
GuaranteedDelivery/BestEffortDelivery 与 SequentialDelivery/NonsequentialDelivery 选项相互独立，可自由组合。每种组合都会产生不同的行为：
理解队头阻塞
队头阻塞发生在送达序列前端的消息尚未到位时。同一序列中后续的消息即使已在接收端，也无法交付给应用。 与队头阻塞相关的选项是SequentialDelivery，而不是 GuaranteedDelivery。顺序送达会构建一个有序序列，其中较早的消息会阻塞较晚的消息。GuaranteedDelivery 可能会 加剧 其影响，因为丢失的消息必须重传而非跳过，这会延长等待时间。使用 BestEffortDelivery + SequentialDelivery 时，空隙会被跳过，序列继续向前推进，因此阻塞窗口较短。
NonsequentialDelivery 消息永远不会被顺序消息阻塞。两种送达模式互不干扰。正在重传的保证顺序消息不会延迟非顺序消息的送达。
实用指南
一种常见的游戏模式是针对不同类型的数据同时使用多种发送选项：GuaranteedDelivery+SequentialDelivery用于顺序和完整性都很重要的游戏状态变更（例如库存更新、比赛状态转换）。BestEffortDelivery+NonsequentialDelivery用于低延迟比完整性更重要的快速变化状态（例如玩家位置、瞄准方向）。
多个独立序列
每个本地端点表示一个独立的序列空间。从一个本地端点发送到某个目标端点的所有顺序消息共享相同的顺序保证。该序列内的队头阻塞只会影响同一序列中的其他顺序消息。 如果你需要在同一对设备之间建立多个独立的有序流 —— 例如每个游戏子系统一个流 —— 可以在每台设备上创建多个本地端点（不超过创建 Party 网络时在PartyNetworkConfiguration.maxEndpointsPerDeviceCount 中指定的上限）。从不同本地端点发送的顺序消息之间不存在任何顺序或送达关系。