Sintaxe
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 | Descrição |
|---|---|
| Default | Usa as PartySendMessageOptions padrão. As opções padrão são BestEffortDelivery, NonsequentialDelivery, CopyDataBuffers, CoalesceOpportunistically e RequireTimelyAcknowledgement. |
| GuaranteedDelivery | Garante que a mensagem seja entregue a todos os destinos, retransmitindo-a se necessário. Este sinalizador de opção garante que a mensagem chegará a cada ponto de extremidade de destino, independentemente da perda de pacotes no ambiente, a menos que o ponto de extremidade de destino seja destruído. As transmissões de pacotes serão repetidas conforme necessário. Este sinalizador de opção funciona bem ao enviar informações de estado importantes que sempre devem chegar ao destino; caso contrário, o destino deve ser removido da rede. Use-o com conteúdo de mensagem que não tenha redundância nem possa ser interpolado/extrapolado se for perdido e que justifique o possível aumento no uso de largura de banda caso sejam necessárias retransmissões de pacotes. Garantir a entrega, por si só, não implica a garantia de uma ordem de entrega específica; use o sinalizador de opção SequentialDelivery para impor a ordenação. |
| BestEffortDelivery | Transmite a mensagem com base no melhor esforço e ignora qualquer perda de pacotes. Este sinalizador de opção solicita apenas uma única tentativa de transmissão da mensagem. Se ocorrer perda de pacotes no ambiente, a transmissão não será repetida, e o aplicativo deverá estar preparado para lidar com a ausência da mensagem. Este sinalizador de opção funciona bem para informações que são atualizadas constantemente e não exigem que todas as atualizações cheguem. Use-o com conteúdo de mensagem que já tenha redundância ou que possa ser interpolado/extrapolado se for perdido e que não justifique largura de banda extra para retransmissão. Este é o padrão se o sinalizador de opção GuaranteedDelivery não for especificado. |
| SequentialDelivery | Entrega a mensagem em ordem em relação às outras mensagens enviadas deste ponto de extremidade local para o ponto de extremidade de destino que também foram enviadas sequencialmente. SequentialDelivery não oferece nenhuma garantia sobre a ordenação das mensagens enviadas de pontos de extremidade locais diferentes e/ou para pontos de extremidade de destino diferentes. Cada par de pontos de extremidade deve ser considerado um espaço de sequência separado. Não há garantias sobre a ordem das mensagens sequenciais em relação às mensagens não sequenciais. Este sinalizador de opção funciona bem para informações de estado que devem chegar ao destino em uma sequência específica, mesmo que isso signifique uma eficiência de rede um pouco menor e, possivelmente, esperar um pouco mais para recebê-las se houver perda ou reordenação de pacotes no ambiente. Usar SequentialDelivery com GuaranteedDelivery pode fazer com que as mensagens sejam enfileiradas no ponto de extremidade de destino enquanto aguardam a chegada de mensagens sequenciais enviadas anteriormente. Isso pode resultar em um aumento percebido da latência quando houver perda ou reordenação de pacotes no ambiente, mas o ponto de extremidade de destino sempre verá todas as mensagens, na mesma ordem em que foram enviadas. Usar SequentialDelivery com BestEffortDelivery pode fazer com que mensagens sejam descartadas se uma delas chegar ao ponto de extremidade de destino fora de ordem e uma mensagem sequencial posterior já tiver sido entregue. O ponto de extremidade de destino sempre verá a sequência avançando, mas pode haver lacunas nessa sequência. Uma mensagem mais antiga nunca será entregue depois de uma mais recente. |
| NonsequentialDelivery | Entrega a mensagem aos destinos assim que ela chega. As mensagens enviadas com a opção de entrega não sequencial não oferecem nenhuma garantia sobre a ordem em que são entregues em relação a quaisquer outras mensagens, sequenciais ou não. Elas serão entregues aos destinos assim que chegarem, o que pode não corresponder à ordem em que foram enviadas se houver perda ou reordenação de pacotes no ambiente. Este sinalizador de opção funciona bem para mensagens que podem ser processadas com segurança em qualquer ordem ou que já têm as próprias informações de ordenação, e quando você deseja a máxima eficiência de rede e a menor latência percebida. Este é o padrão se o sinalizador de opção SequentialDelivery não for especificado. |
| CopyDataBuffers | Instrui a biblioteca do Party a fazer uma cópia dos buffers de dados fornecidos para transmissão posterior. O conteúdo da memória nas estruturas PartyDataBuffer fornecidas será copiado para que o chamador não precise manter os buffers depois que PartyLocalEndpoint::SendMessage() retornar. Isso é mais conveniente, mas um pouco menos eficiente do que usar o sinalizador de opção DontCopyDataBuffers. Este é o padrão se o sinalizador de opção DontCopyDataBuffers não for especificado. |
| DontCopyDataBuffers | Informa à biblioteca do Party que use os buffers de dados fornecidos diretamente e que o chamador manterá a memória válida até que a biblioteca não precise mais deles. A memória referenciada pelas estruturas PartyDataBuffer fornecidas não será copiada; em vez disso, a propriedade será transferida temporariamente para a biblioteca do Party para que a memória possa ser acessada diretamente, sem sobrecarga adicional de cópia durante o processo de transmissão. É responsabilidade do chamador garantir que os buffers de memória permaneçam válidos e sem modificações até que a biblioteca não precise mais deles e a propriedade seja devolvida por meio de um PartyDataBuffersReturnedStateChange. Isso é mais eficiente, mas pode ser menos conveniente do que usar a opção CopyDataBuffers. As próprias estruturas PartyDataBuffer não precisam permanecer válidas após o retorno da chamada a PartyLocalEndpoint::SendMessage(), apenas a memória que elas referenciam. |
| CoalesceOpportunistically | Especifica que esta mensagem deve ser combinada com quaisquer outras mensagens enfileiradas, mas não deve atrasar a transmissão se não houver nenhuma aguardando. Combinar várias mensagens em um único pacote permite maximizar a eficiência da largura de banda (reduzindo a sobrecarga por pacote), com um possível custo na latência percebida de uma mensagem se você atrasar a transmissão dela para combiná-la. Enviar com este sinalizador faz com que a biblioteca do Party combine a mensagem se houver outras mensagens enfileiradas disponíveis, mas sem esperar por mais mensagens se não houver nenhuma e esta mensagem puder ser transmitida imediatamente. Use este sinalizador se você normalmente agrupa suas atualizações de rede em mensagens únicas e periódicas que provavelmente não ficarão enfileiradas ao mesmo tempo que outras mensagens e que não ganhariam eficiência de largura de banda se fossem atrasadas. Este sinalizador não garante que a mensagem comece a ser transmitida imediatamente. Se a qualidade da conexão ou a capacidade de resposta do receptor não parecerem suportar o envio de dados adicionais no momento, a mensagem poderá ser enfileirada para aguardar a próxima oportunidade de transmissão. Este é o padrão se o sinalizador de opção AlwaysCoalesceUntilFlushed não for especificado. |
| AlwaysCoalesceUntilFlushed | Especifica que esta mensagem sempre deve tentar ser combinada com outras mensagens e aguardar uma chamada a PartyLocalEndpoint::FlushMessages() para começar a ser transmitida. Combinar várias mensagens em um único pacote permite maximizar a eficiência da largura de banda (reduzindo a sobrecarga por pacote), com um possível custo na latência percebida de uma mensagem se você atrasar a transmissão dela para combiná-la. Enviar com este sinalizador faz com que a biblioteca do Party sempre prefira combinar a mensagem e atrase a transmissão até que PartyLocalEndpoint::FlushMessages() seja chamado. Considere usar este sinalizador se você normalmente envia muitas mensagens pequenas para os mesmos destinos no mesmo loop de atualização e deseja informar explicitamente à biblioteca do Party quando a iteração completa do loop de atualização for concluída. Mesmo com este sinalizador, há cenários em que a mensagem pode começar a ser transmitida sem exigir uma chamada explícita a PartyLocalEndpoint::FlushMessages(). Isso pode ocorrer quando há outras mensagens enfileiradas que já estão sendo transmitidas por outros motivos e há espaço no pacote para incluir esta mensagem. Da mesma forma, quando houver bytes de dados de mensagens suficientes para enviar um pacote completo e nenhuma combinação adicional for possível, o pacote será enviado. Chamar PartyLocalEndpoint::FlushMessages() quando todas as mensagens já tiverem começado a ser transmitidas é inofensivo. |
| RequireTimelyAcknowledgement | Indica que esta mensagem deve ser confirmada (se necessário) em tempo hábil. Os receptores confirmam o recebimento das mensagens para informar o remetente sobre o êxito ou a falha da entrega, para que ele possa, por exemplo, repetir o envio de pacotes descartados que continham mensagens enviadas com o sinalizador de opção GuaranteedDelivery. As confirmações costumam ser incluídas em pacotes como parte da comunicação bidirecional típica, mas, se nenhum pacote estiver fluindo na direção de retorno, este sinalizador instrui os pontos de extremidade de destino a aguardar apenas um pequeno tempo limite, gerenciado internamente, por oportunidades de inclusão antes de forçar o envio de pacotes de confirmação para informar o remetente. Esse pacote dedicado consome alguma sobrecarga extra, mas garante que o remetente receba o status em tempo hábil para emitir as novas tentativas necessárias. É recomendável usar este sinalizador para a maioria das mensagens com entrega garantida. Ele funciona bem com mensagens sensíveis à latência. Também funciona bem quando os padrões de envio bidirecional com entrega garantida são pouco frequentes ou imprevisíveis. Este é o padrão se o sinalizador de opção AllowLazyAcknowledgement não for especificado. Este sinalizador será ignorado se o sinalizador de opção GuaranteedDelivery não for especificado. |
| AllowLazyAcknowledgement | Indica que esta mensagem pode ser confirmada quando for conveniente, em vez de com urgência. Os receptores confirmam o recebimento das mensagens para informar o remetente sobre o êxito ou a falha da entrega, para que ele possa, por exemplo, repetir o envio de pacotes descartados que continham mensagens enviadas com o sinalizador de opção GuaranteedDelivery. As confirmações costumam ser incluídas em pacotes como parte da comunicação bidirecional típica, mas, se nenhum pacote estiver fluindo na direção de retorno, este sinalizador instrui os pontos de extremidade de destino a aguardar oportunidades de inclusão sem forçar o envio de pacotes de confirmação para informar o remetente. Isso atrasa o momento em que o remetente descobre o status para as novas tentativas necessárias, mas evita a sobrecarga extra consumida por um pacote dedicado. Considere usar este sinalizador para mensagens com entrega garantida do tipo “enviar e esquecer” que não sejam sensíveis à latência. Ele também pode reduzir a sobrecarga quando os padrões de envio bidirecional são frequentes. Este sinalizador será ignorado se o sinalizador de opção GuaranteedDelivery também não for especificado. |
Requisitos
Cabeçalho: Party.hConfira também
Membros do PartyPartySendMessageQueuingConfiguration
PartyDataBuffersReturnedStateChange
PartyLocalEndpoint::SendMessage
PartyLocalEndpoint::FlushMessages