> ## Documentation Index
> Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Opções de transporte

> Compare as opções de transporte do PlayFab Party, incluindo a retransmissão em nuvem transparente e a conectividade direta ponto a ponto, e como cada uma afeta a latência, o NAT e a confiabilidade.

# Configurando o comportamento de transporte

Os recursos de rede do PlayFab Party ampliam os recursos do User Datagram Protocol (UDP) da plataforma nativa para fornecer mecanismos de transporte de datagramas ideais para jogos multijogador em tempo real.

Enquanto o Transmission Control Protocol (TCP) fornece fluxos confiáveis e o UDP fornece datagramas não confiáveis, você pode configurar o comportamento de rede do Party por datagrama. Ao usar [PartyLocalEndpoint::SendMessage](/pt-BR/services/playfab/multiplayer/networking/reference/classes/PartyLocalEndpoint/methods/partylocalendpoint_sendmessage) para transmitir um datagrama de um ponto de extremidade local do Party para um ponto de extremidade remoto, especifique [PartySendMessageOptions](/pt-BR/services/playfab/multiplayer/networking/reference/enums/partysendmessageoptions) para ajustar o comportamento de transporte desejado.

Os recursos incluem:

* **Entrega garantida**: o sinalizador `GuaranteedDelivery` garante que a mensagem chegue a todos os destinos, retransmitindo dados implicitamente, se necessário, para atenuar a perda de pacotes do ambiente. Esse sinalizador de opção funciona bem ao enviar informações de estado importantes que sempre devem chegar ao destino ou, caso contrário, o destino deve ser removido da rede. A opção padrão é `BestEffortDelivery`, que fornece um comportamento do tipo "disparar e esquecer", semelhante ao UDP.
* **Entrega sequencial**: ordena a entrega da mensagem em relação a outras mensagens enviadas sequencialmente deste ponto de extremidade local para o ponto de extremidade de destino. Use esse sinalizador de opção para enviar informações de estado que devem chegar ao destino em uma sequência específica. A entrega sequencial pode resultar em uma eficiência de rede um pouco menor e em uma espera mais longa para receber todos os pacotes quando há perda ou reordenação de pacotes pelo ambiente. Usar `SequentialDelivery` com `GuaranteedDelivery` pode fazer com que as mensagens fiquem enfileiradas no ponto de extremidade de destino enquanto aguardam a chegada de mensagens sequenciais enviadas anteriormente. O enfileiramento pode aumentar a latência percebida durante a perda ou reordenação de pacotes no ambiente, mas o ponto de extremidade de destino sempre vê todas as mensagens na ordem em que foram enviadas. Essa compensação de desempenho é comum em protocolos semelhantes ao TCP e às vezes é chamada de [bloqueio de cabeça de fila](https://wikipedia.org/wiki/Head-of-line_blocking).
* **Agrupamento**: a biblioteca do Party fragmenta e remonta automaticamente mensagens grandes que excedem o tamanho máximo com suporte do ambiente, para que os chamadores não precisem gerenciar a fragmentação. Se você estiver enviando muitos datagramas pequenos, o agrupamento os combina em um único pacote para melhorar a eficiência da largura de banda, ao custo potencial de latência adicional. Enviar com o sinalizador `CoalesceOpportunistically` (o padrão) agrupa a mensagem com outras mensagens enfileiradas, se houver alguma disponível, mas não espera por mais se a mensagem puder ser transmitida imediatamente. Enviar com o sinalizador `AlwaysCoalesceUntilFlushed` atrasa a transmissão até que `PartyLocalEndpoint::FlushMessages` seja chamado; nesse momento, as mensagens enfileiradas são agrupadas e transmitidas.

<img src="https://mintcdn.com/microsoft-4404708b/dqv53299jA1M-fNi/images/playfab/multiplayer/networking/party-networking-options.png?fit=max&auto=format&n=dqv53299jA1M-fNi&q=85&s=425329288a87d5e8de651901cba334eb" alt="Opções de transporte do Party" width="470" height="325" data-path="images/playfab/multiplayer/networking/party-networking-options.png" />

## Combinando opções de entrega e sequenciamento

As opções `GuaranteedDelivery`/`BestEffortDelivery` e `SequentialDelivery`/`NonsequentialDelivery` são independentes e podem ser combinadas livremente. Cada combinação produz um comportamento distinto:

| Entrega | Sequenciamento | Comportamento |
| - | - | - |
| `GuaranteedDelivery` | `SequentialDelivery` | Confiável e ordenada. Todas as mensagens chegam na ordem em que foram enviadas. Se uma mensagem for perdida em trânsito, as mensagens sequenciais posteriores ficarão enfileiradas no destinatário até que a mensagem ausente seja retransmitida e entregue. Mais suscetível ao bloqueio de cabeça de fila. |
| `GuaranteedDelivery` | `NonsequentialDelivery` | Confiável e não ordenada. Todas as mensagens chegam, mas cada uma é entregue ao aplicativo assim que chega, independentemente da ordem de envio. Sem bloqueio de cabeça de fila. |
| `BestEffortDelivery` | `SequentialDelivery` | Não confiável e ordenada. As mensagens são entregues em ordem, mas lacunas são permitidas. Se uma mensagem chegar depois que uma mensagem sequencial posterior já tiver sido entregue, a mensagem atrasada será descartada. A sequência sempre avança. |
| `BestEffortDelivery` | `NonsequentialDelivery` | Não confiável e não ordenada (o padrão). "Disparar e esquecer": cada mensagem é entregue assim que chega, sem garantias de ordenação ou de entrega. Menor latência. |

### Entendendo o bloqueio de cabeça de fila

O bloqueio de cabeça de fila acontece quando uma mensagem no início de uma sequência de entrega ainda não está disponível. As mensagens posteriores na mesma sequência não podem ser entregues ao aplicativo, mesmo que o destinatário já as tenha.

A opção relevante para o bloqueio de cabeça de fila é **`SequentialDelivery`**, não `GuaranteedDelivery`. A entrega sequencial cria uma sequência ordenada em que as mensagens anteriores bloqueiam as posteriores. `GuaranteedDelivery` pode *exagerar* o impacto, porque uma mensagem ausente precisa ser retransmitida em vez de ignorada, o que prolonga a espera. Com `BestEffortDelivery` + `SequentialDelivery`, uma lacuna é ignorada e a sequência avança, portanto a janela de bloqueio é curta.

As mensagens `NonsequentialDelivery` nunca são bloqueadas por mensagens sequenciais. Os dois modos de entrega não interferem um no outro. Uma mensagem sequencial garantida em retransmissão não atrasa a entrega de uma mensagem não sequencial.

### Orientações práticas

Um padrão comum em jogos usa várias opções de envio simultaneamente para diferentes tipos de dados:

* **`GuaranteedDelivery` + `SequentialDelivery`** para alterações de estado do jogo em que a ordenação e a integridade importam (por exemplo, atualizações de inventário, transições de estado da partida).
* **`BestEffortDelivery` + `NonsequentialDelivery`** para estados que mudam rapidamente, em que a baixa latência importa mais do que a integridade (por exemplo, posições dos jogadores, direção da mira).

Como as mensagens sequenciais e não sequenciais são independentes, uma mensagem de alteração de estado em retransmissão não atrasa a entrega das atualizações de posição.

### Várias sequências independentes

Cada ponto de extremidade local representa um espaço de sequência independente. Todas as mensagens sequenciais enviadas de um ponto de extremidade local para um determinado ponto de extremidade de destino compartilham as mesmas garantias de ordenação. O bloqueio de cabeça de fila dentro dessa sequência só pode afetar outras mensagens sequenciais na mesma sequência.

Se você precisar de vários fluxos ordenados independentes entre os mesmos dois dispositivos (por exemplo, um fluxo por subsistema do jogo), poderá criar vários pontos de extremidade locais em cada dispositivo (até o limite especificado em `PartyNetworkConfiguration.maxEndpointsPerDeviceCount` quando a rede do Party é criada). As mensagens sequenciais enviadas de pontos de extremidade locais diferentes não têm nenhuma relação de ordenação ou de entrega entre si.

## Estatísticas de rede e enfileiramento local

Dependendo das opções de envio de mensagens e do estado da rede, o Party pode enfileirar mensagens localmente antes da transmissão. Esse enfileiramento local é gerenciado cuidadosamente para evitar a introdução de latência. O enfileiramento é necessário para garantir que o Party não sobrecarregue a rede do jogador e que recursos como o agrupamento possam ser aplicados.

[PartyNetwork::GetNetworkStatistics](/pt-BR/services/playfab/multiplayer/networking/reference/classes/PartyNetwork/methods/partynetwork_getnetworkstatistics) coleta dados sobre o desempenho agregado da rede, incluindo a latência até o serviço de retransmissão do Party.

[PartyLocalEndpoint::GetEndpointStatistics](/pt-BR/services/playfab/multiplayer/networking/reference/classes/PartyLocalEndpoint/methods/partylocalendpoint_getendpointstatistics) fornece visibilidade das estatísticas de enfileiramento e de perda de pacotes de um ponto de extremidade remoto específico.


## Related topics

- [PAGE 111 · Transporte acessível para eventos de jogos](/pt-BR/build/game-principles/accessibility/page/page-111-transportation.md)
- [Recursos do PlayFab Party](/pt-BR/services/playfab/multiplayer/networking/party-features.md)
- [PAGE · Listas de verificação de acessibilidade de pré-planejamento e pós-evento](/pt-BR/build/game-principles/accessibility/page/page-checklists.md)
- [Erros de transporte do XTF](/pt-BR/tools/tools-console/commandlinetools/xtf-transport-errors.md)
- [Opções de teste de pré-lançamento](/pt-BR/publishing/game-publishing/publishing-processes/managed-creators/publishing-processes-prerelease.md)
