Sintaxis
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,
}
Constantes
| Constante | Descripción |
|---|---|
| Default | Usar las PartySendMessageOptions predeterminadas. Las opciones predeterminadas son BestEffortDelivery, NonsequentialDelivery, CopyDataBuffers, CoalesceOpportunistically y RequireTimelyAcknowledgement. |
| GuaranteedDelivery | Garantizar que el mensaje se entregue a todos los destinos, retransmitiéndolo si es necesario. Esta marca de opción garantiza que el mensaje llegará a cada punto de conexión de destino, independientemente de la pérdida de paquetes del entorno, a menos que el punto de conexión de destino se destruya. Las transmisiones de paquetes se reintentarán según sea necesario. Esta marca de opción funciona bien al enviar información de estado importante que siempre debe llegar al destino o, de lo contrario, el destino debe quitarse de la red. Úsela con contenido de mensaje que no tenga redundancia ni la capacidad de interpolarse/extrapolarse si se pierde, y que valga la pena el posible aumento del uso de ancho de banda en caso de que se necesiten retransmisiones de paquetes. Garantizar la entrega por sí mismo no implica una garantía de un orden de entrega concreto; use la marca de opción SequentialDelivery para exigir el orden. |
| BestEffortDelivery | Transmitir el mensaje con el mejor esfuerzo posible e ignorar cualquier pérdida de paquetes. Esta marca de opción solicita un único intento de transmitir el mensaje. Si se produce una pérdida de paquetes del entorno, la transmisión no se reintentará y la aplicación debe estar preparada para controlar la ausencia del mensaje. Esta marca de opción funciona bien para información que se actualiza constantemente y que no requiere que llegue cada actualización. Úsela con contenido de mensaje que ya tenga redundancia o la capacidad de interpolarse/extrapolarse si se pierde y que no valga la pena el ancho de banda adicional de retransmitir. Este es el valor predeterminado si no se especifica la marca de opción GuaranteedDelivery. |
| SequentialDelivery | Entregar el mensaje en orden con respecto a otros mensajes enviados desde este punto de conexión local al punto de conexión de destino que también se enviaron secuencialmente. SequentialDelivery no proporciona ninguna garantía sobre el orden de los mensajes enviados desde distintos puntos de conexión locales o a distintos puntos de conexión de destino. Cada emparejamiento de puntos de conexión debe considerarse un espacio de secuencia independiente. No se ofrecen garantías sobre el orden de los mensajes secuenciales en relación con los mensajes no secuenciales. Esta marca de opción funciona bien para información de estado que debe llegar al destino en una secuencia concreta, incluso si eso significa una eficiencia de red ligeramente menor y posiblemente esperar un poco más para recibirla si hay pérdida de paquetes o reordenación por parte del entorno. El uso de SequentialDelivery con GuaranteedDelivery puede provocar que los mensajes se pongan en cola en el punto de conexión de destino mientras se espera que lleguen los mensajes secuenciales enviados previamente. Esto puede provocar un aumento percibido de la latencia cuando se experimenta pérdida de paquetes o reordenación del entorno, pero el punto de conexión de destino siempre verá todos los mensajes, en el mismo orden en que se enviaron. El uso de SequentialDelivery con BestEffortDelivery puede provocar que se descarten mensajes si uno llega al punto de conexión de destino fuera de orden y ya se había entregado un mensaje secuencial posterior. El punto de conexión de destino siempre verá la secuencia avanzando, pero puede haber lagunas en esa secuencia. Un mensaje más antiguo nunca se entregará después de uno más reciente. |
| NonsequentialDelivery | Entregar el mensaje a los destinos tan pronto como llegue. Los mensajes enviados con la opción de entrega no secuencial no proporcionan ninguna garantía sobre el orden en que se entregan con respecto a cualquier otro mensaje, secuencial o no secuencial. Se entregarán a los destinos tan pronto como lleguen, que puede no ser el mismo orden en que se enviaron si hay pérdida de paquetes o reordenación por parte del entorno. Esta marca de opción funciona bien para mensajes que son seguros de procesar en cualquier orden o que ya tienen su propia información de orden inherente, y cuando desea la máxima eficiencia de red y la menor latencia percibida. Este es el valor predeterminado si no se especifica la marca de opción SequentialDelivery. |
| CopyDataBuffers | Indica a la biblioteca de Party que haga una copia de los búferes de datos proporcionados para su transmisión posterior. El contenido de la memoria de las estructuras PartyDataBuffer proporcionadas se copiará, por lo que el autor de la llamada no necesita conservar los búferes después de que PartyLocalEndpoint::SendMessage() devuelva. Esto es más cómodo pero ligeramente menos eficiente que usar la marca de opción DontCopyDataBuffers. Este es el valor predeterminado si no se especifica la marca de opción DontCopyDataBuffers. |
| DontCopyDataBuffers | Informa a la biblioteca de Party de que use los búferes de datos proporcionados directamente y de que el autor de la llamada mantendrá la memoria válida hasta que la biblioteca ya no los necesite. La memoria a la que hacen referencia las estructuras PartyDataBuffer proporcionadas no se copiará; en su lugar, la propiedad se transferirá temporalmente a la biblioteca de Party para que se pueda acceder directamente a la memoria sin sobrecarga adicional de copia durante el proceso de transmisión. Es responsabilidad del autor de la llamada garantizar que los búferes de memoria permanezcan válidos y sin modificar hasta que la biblioteca ya no los necesite y la propiedad se transfiera de vuelta mediante un PartyDataBuffersReturnedStateChange. Esto es más eficiente pero puede ser menos cómodo que usar la opción CopyDataBuffers. Las propias estructuras PartyDataBuffer no necesitan permanecer válidas después de que la llamada a PartyLocalEndpoint::SendMessage() devuelva, solo la memoria a la que hacen referencia. |
| CoalesceOpportunistically | Especifica que este mensaje debe fusionarse con cualquier otro mensaje en cola, pero no debe retrasar la transmisión si no hay ninguno en espera. Fusionar varios mensajes en un solo paquete permite maximizar la eficiencia del ancho de banda (reduciendo la sobrecarga por paquete) a costa potencial de la latencia percibida de un mensaje si se retrasa su transmisión para fusionarlo. Enviar con esta marca hace que la biblioteca de Party fusione el mensaje si hay otros mensajes en cola disponibles, pero no que espere más mensajes si no existe ninguno y este mensaje puede transmitirse inmediatamente. Use esta marca si normalmente agrupa por lotes sus actualizaciones de red en mensajes únicos y periódicos que no es probable que se pongan en cola al mismo tiempo que otros mensajes y que no ganarían eficiencia de ancho de banda si se retrasaran. Esta marca no garantiza que el mensaje comience a transmitirse inmediatamente. Si la calidad de la conexión o la capacidad de respuesta del receptor no parecen admitir actualmente el envío de datos adicionales todavía, el mensaje puede ponerse en cola para esperar la próxima oportunidad de transmisión. Este es el valor predeterminado si no se especifica la marca de opción AlwaysCoalesceUntilFlushed. |
| AlwaysCoalesceUntilFlushed | Especifica que este mensaje siempre debe intentar fusionarse con otros mensajes y esperar una llamada a PartyLocalEndpoint::FlushMessages() para comenzar la transmisión. Fusionar varios mensajes en un solo paquete permite maximizar la eficiencia del ancho de banda (reduciendo la sobrecarga por paquete) a costa potencial de la latencia percibida de un mensaje si se retrasa su transmisión para fusionarlo. Enviar con esta marca hace que la biblioteca de Party siempre prefiera fusionar el mensaje y retrasar la transmisión hasta que se llame a PartyLocalEndpoint::FlushMessages(). Considere la posibilidad de usar esta marca si normalmente envía muchos mensajes pequeños a los mismos destinos en el mismo bucle de actualización y desea informar explícitamente a la biblioteca de Party cuando la iteración completa del bucle de actualización haya terminado. Incluso con esta marca hay escenarios en los que el mensaje podría comenzar a transmitirse sin requerir una llamada explícita a PartyLocalEndpoint::FlushMessages(). Esto puede ocurrir cuando hay otros mensajes en cola que ya se están transmitiendo por otros motivos y hay espacio en el paquete para incluir este mensaje. De forma similar, cuando existen suficientes bytes de datos de mensaje para enviar un paquete completo y no es posible más fusión, el paquete se enviará. Llamar a PartyLocalEndpoint::FlushMessages() cuando todos los mensajes ya han comenzado a transmitirse es benigno. |
| RequireTimelyAcknowledgement | Indica que este mensaje debe confirmarse (si es necesario) de manera oportuna. Los receptores confirman la recepción de los mensajes para informar al emisor del éxito o el fracaso de la entrega, de modo que pueda hacer cosas como reintentar los paquetes descartados que contenían mensajes enviados con la marca de opción GuaranteedDelivery. Las confirmaciones a menudo se incorporan a los paquetes como parte de la comunicación bidireccional típica, pero si no fluyen paquetes en la dirección de retorno, esta marca indica a los puntos de conexión de destino que solo esperen un pequeño tiempo de espera administrado internamente para las oportunidades de incorporación antes de forzar paquetes de confirmación para informar al emisor. Ese paquete dedicado consume algo de sobrecarga adicional, pero garantiza que el emisor obtenga el estado de manera oportuna para emitir los reintentos necesarios. Se recomienda usar esta marca para la mayoría de los mensajes de entrega garantizada. Funciona bien con mensajes sensibles a la latencia. También funciona bien cuando los patrones de envío de entrega garantizada bidireccionales son poco frecuentes o impredecibles. Este es el valor predeterminado si no se especifica la marca de opción AllowLazyAcknowledgement. Esta marca se ignora si no se especifica la marca de opción GuaranteedDelivery. |
| AllowLazyAcknowledgement | Indica que este mensaje puede confirmarse cuando sea conveniente en lugar de con urgencia. Los receptores confirman la recepción de los mensajes para informar al emisor del éxito o el fracaso de la entrega, de modo que pueda hacer cosas como reintentar los paquetes descartados que contenían mensajes enviados con la marca de opción GuaranteedDelivery. Las confirmaciones a menudo se incorporan a los paquetes como parte de la comunicación bidireccional típica, pero si no fluyen paquetes en la dirección de retorno, esta marca indica a los puntos de conexión de destino que esperen oportunidades de incorporación sin forzar paquetes de confirmación para informar al emisor. Esto retrasa que el emisor conozca el estado para los reintentos necesarios, pero evita la sobrecarga adicional que consume un paquete dedicado. Considere la posibilidad de usar esta marca para mensajes de entrega garantizada que sean de tipo “enviar y olvidar” y que no sean sensibles a la latencia. También puede reducir la sobrecarga cuando los patrones de envío bidireccionales son frecuentes. Esta marca se ignora si no se especifica también la marca de opción GuaranteedDelivery. |
Requisitos
Encabezado: Party.hConsulte también
Miembros de PartyPartySendMessageQueuingConfiguration
PartyDataBuffersReturnedStateChange
PartyLocalEndpoint::SendMessage
PartyLocalEndpoint::FlushMessages