Faz sentido usar o TCP e o UDP de uma só vez?

Depois de ler O UDP ainda é melhor que o TCP para jogos em tempo real com muitos dados? , Gostaria de saber se faz sentido usar o TCP e o UDP ao mesmo tempo, mas para coisas diferentes:

• TCP para o envio de informações enviadas com pouca frequência, mas com garantia de chegada confiável.
  Como atualizações de pontuação, o nome de um jogador ou até o estado on / off de uma luz no mundo do jogo.

• UDP para transmissão de informações atualizadas constantemente e que podem ser perdidas ocasionalmente, pois as informações mais recentes estão sempre a caminho.
  Como posição, rotação, etc.

Esta é uma ideia razoável? Quais são as possíveis desvantagens?
Existem maneiras melhores de lidar com isso?

Isso resulta em perda de pacotes para o UDP devido à contenção entre os dois protocolos - lembre-se de que o UDP não tem entrega garantida, enquanto o TCP é. Mais pacotes TCP passarão enquanto o UDP sofrer - o TCP induz a perda de pacotes UDP . Também houve a idéia (histórica) de que a infraestrutura do roteador favorece o TCP sobre o UDP, embora eu duvide que isso ainda seja verdade nesta fase tardia.

Eu acho que seria melhor encontrar um dos protocolos UDP orientados à conexão disponíveis para uso em jogos e similares, que oferece alguns dos benefícios do TCP sem nenhuma desvantagem. Existem alguns deles, geralmente com um whitepaper detalhando cada conceito.

Um exemplo disso é a biblioteca Enet de código aberto , cujo principal recurso é a entrega opcional e confiável e em ordem de pacotes pelo UDP.

Aqui está uma citação de Sam Jansen de um comentário no gafferongames.com :

Falando como pesquisador de rede e não como desenvolvedor de jogos, a conclusão de nunca usar TCP e UDP juntos parece um pouco forte. O TCP só terá perda de pacotes se estiver enviando muitos dados; de certa forma, assim como os dados UDP que você está enviando. A diferença é que você não tem controle direto sobre a taxa que o TCP envia, isso está oculto para você.

Se você apenas precisar enviar alguns dados confiáveis ​​e não quiser se preocupar com retransmissão e implementação de um protocolo confiável, e souber que a taxa será baixa, não haverá problemas ao usar o TCP e o UDP.

O relacionamento não é tão complexo entre os dois: o TCP apenas aumenta sua taxa de envio (se houver dados a serem enviados) até obter perda de pacotes; nesse caso, ele retorna sua taxa e começa a aumentar novamente a taxa (isso tempo mais devagar). Quando seu aumento na taxa causa perda de pacotes, é provável que também ocorra qualquer outro fluxo de dados, incluindo os pacotes UDP.

O documento Características da perda de pacotes UDP: Efeito do tráfego TCP obteve seus resultados abrindo várias conexões TCP de uma só vez e inundando a rede com dados. Isso leva ao congestionamento seguido pela sincronização global , que causa a queda de pacotes. Obviamente, um cliente de jogo não abrirá uma dúzia de conexões de uma só vez e inundará a rede com dados e, portanto, seus resultados serão diferentes.

Para responder sua pergunta:

Gostaria de saber se faz sentido usar o TCP e o UDP ao mesmo tempo, mas para coisas diferentes [...]

Sim, isso é algo aceitável, desde que você permaneça dentro dos limites da largura de banda.

• TCP para o envio de informações enviadas com pouca frequência, mas com garantia de chegada confiável. Como atualizações de pontuação, o nome de um jogador ou até o estado on / off de uma luz no mundo do jogo.

Ao usar o TCP e o UDP, você sempre deve preferir enviar o máximo possível pelo UDP e o mínimo possível pelo TCP.

Agora, pergunto-lhe o seguinte: é realmente necessário enviar a pontuação, o nome do jogador e o estado da luz sobre o TCP? Embora seja verdade que você precise receber esses dados eventualmente, é verdade que você precisa receber esses dados estritamente em ordem e exatamente uma vez?

Provavelmente não.

O UDP funciona bem nesses casos, e o Quake 3 é um bom exemplo de como.

Então, qual é um bom exemplo de TCP ao lado de UDP? Bem, pense na caixa de bate-papo de um jogo. As atualizações nesta caixa de bate-papo (ou seja, as novas linhas de texto) precisam ser enviadas de maneira confiável e estritamente em ordem. Assim, o TCP é um bom ajuste.

Esta é uma ideia razoável?

• sim

Quais são as possíveis desvantagens?

• Perda de pacotes, mais complexidade de código, outra conexão para gerenciar == mais chances de desconexões, tempos limites, exceções, qualquer que seja ...

Existem maneiras melhores de lidar com isso?

• Use uma biblioteca UDP confiável existente. Dois dos mais populares são: Rede Lidgren (C #), RakNet (C ++). Por experiência, posso dizer que o Lidgren é super fácil de usar, rápido e confiável.

Há uma restrição de recurso adicional a considerar. A maioria das implementações (acredito em tudo, mas não tenho referência) do TCP no servidor tem limites para quantas conexões TCP simultâneas o servidor pode ter aberto ao mesmo tempo. Isso limitaria o número de jogadores que você pode abrir ao mesmo tempo se cada jogador precisar de sua própria conexão.

Os limites são definidos pelas configurações no sistema de rede. Além disso, toda conexão consome alguma memória que precisa vir de algum lugar no servidor.

Uma solução é abrir apenas uma conexão TCP temporária enquanto os dados são transferidos e fechá-la imediatamente. Isso tornará as transações mais lentas, a abertura de um tcp Connection é um processo bastante "caro". Como sempre, trata-se de projetar um sistema robusto desde o início, a fim de permitir um grande crescimento.