Est-il judicieux d'utiliser à la fois TCP et UDP à la fois?

Après lecture UDP est-il toujours meilleur que TCP pour les jeux en temps réel riches en données? , Je me demande s'il est logique d'utiliser à la fois TCP et UDP en même temps, mais pour des choses différentes:

• TCP pour l'envoi d'informations rarement envoyées, mais dont la fiabilité doit être garantie.
  Tels que les mises à jour de score, le nom d'un joueur ou même l'état allumé / éteint d'une lumière dans le monde du jeu.

• UDP pour transmettre des informations qui sont constamment mises à jour et peuvent être perdues occasionnellement, car des informations plus récentes sont toujours en route.
  Tels que la position, la rotation, etc.

Est-ce une idée raisonnable? Quels sont les inconvénients possibles?
Y a-t-il de meilleures façons de gérer cela?

Il en résulte une perte de paquets pour UDP en raison de conflits entre les deux protocoles - rappelez-vous que UDP n'est pas une livraison garantie, tandis que TCP l'est. Plus de paquets TCP passeront alors que UDP souffre - TCP induit une perte de paquets UDP . Il y a également eu l'idée (historique) que l'infrastructure de routeur favorise TCP sur UDP, bien que je doute que ce soit toujours vrai à ce stade avancé.

Je pense que vous feriez mieux de trouver l'un des protocoles UDP orientés connexion disponibles pour les jeux et similaires, qui vous offre certains des avantages de TCP sans aucun de ses inconvénients. Il y en a quelques-uns, généralement avec un livre blanc détaillant chaque concept.

Un exemple de ceux-ci est la bibliothèque open source Enet , sa principale caractéristique étant la livraison optionnelle fiable et dans l'ordre des paquets via UDP.

Voici une citation de Sam Jansen d'un commentaire sur gafferongames.com :

S'exprimant en tant que chercheur réseau et non développeur de jeux, la conclusion de ne jamais utiliser TCP et UDP ensemble semble un peu forte. TCP n'aura de perte de paquets que s'il envoie trop de données; à certains égards, tout comme les données UDP que vous envoyez. La différence est que vous n'avez aucun contrôle direct sur le taux d'envoi de TCP, cela vous est caché.

Si vous avez juste besoin d'envoyer des données fiables et que vous ne voulez pas vous soucier de la retransmission et de la mise en œuvre d'un protocole fiable, et que vous savez que le débit sera faible, il n'y aura aucun problème avec l'utilisation de TCP et UDP.

La relation n'est pas vraiment complexe entre les deux: TCP augmente simplement son débit d'envoi (s'il y a des données à envoyer) jusqu'à ce qu'il obtienne la perte de paquets, auquel cas il rappelle son débit, puis recommence à augmenter le débit (ce plus lentement). Lorsque son augmentation de débit entraîne une perte de paquets, il est très probable qu'il frappe également tout autre flux de données, y compris vos paquets UDP.

L'article Caractéristiques de la perte de paquets UDP: effet du trafic TCP a obtenu ses résultats en ouvrant plusieurs connexions TCP à la fois et en inondant le réseau de données. Cela conduit à la congestion suivie d' une synchronisation globale , qui provoquent toutes deux la perte de paquets. De toute évidence, un client de jeu n'ouvrira pas une douzaine de connexions à la fois et inondera le réseau de données, et donc vos résultats seront différents.

Pour répondre à ta question:

Je me demande s'il est logique d'utiliser à la fois TCP et UDP en même temps, mais pour des choses différentes [...]

Oui, c'est une chose acceptable à faire en supposant que vous restiez dans les limites de votre bande passante.

• TCP pour l'envoi d'informations rarement envoyées, mais dont la fiabilité doit être garantie. Tels que les mises à jour de score, le nom d'un joueur ou même l'état allumé / éteint d'une lumière dans le monde du jeu.

Lorsque vous utilisez à la fois TCP et UDP, vous devriez toujours préférer envoyer autant que possible sur UDP et aussi peu que possible sur TCP.

Maintenant, je vous demande ceci: est-il vraiment nécessaire d'envoyer le score, le nom du joueur et l'état d'une lumière sur TCP? S'il est vrai que vous devez éventuellement recevoir ces données, est-il vrai que vous devez recevoir ces données strictement dans l'ordre et exactement une fois?

Probablement pas.

UDP fonctionne bien pour ces cas, et Quake 3 est un bon exemple de comment.

Alors, quel est un bon exemple de TCP avec UDP? Eh bien, pensez à la boîte de dialogue d'un jeu. Les mises à jour de cette boîte de discussion (c'est-à-dire les nouvelles lignes de texte) doivent être envoyées de manière fiable et strictement dans l'ordre. TCP est donc un bon choix.

Est-ce une idée raisonnable?

• Oui

Quels sont les inconvénients possibles?

• Perte de paquets, plus de complexité de code, une autre connexion pour gérer == plus de chances de déconnexions, de délais d'expiration, d'exceptions, etc.

Y a-t-il de meilleures façons de gérer cela?

• Utilisez une bibliothèque UDP fiable existante. Deux des plus populaires sont: Lidgren Network (C #), RakNet (C ++). Par expérience, je peux dire que Lidgren est super facile à utiliser, rapide et fiable.

Il y a une contrainte de ressource supplémentaire à considérer. La plupart des implémentations (je crois tout, mais sans référence) de TCP sur le serveur ont des limites sur le nombre de connexions TCP simultanées que le serveur peut avoir ouvertes en même temps. Cela limiterait le nombre de joueurs que vous pouvez ouvrir en même temps si chaque joueur a besoin de sa propre connexion.

Les limites sont définies par les paramètres du système réseau. De plus, chaque connexion utilise de la mémoire qui doit provenir de quelque part sur le serveur.

Une solution consiste à ouvrir uniquement une connexion TCP temporaire pendant le transfert des données et à la fermer immédiatement. Cela ralentira les transactions, l'ouverture d'une connexion TCP est un processus plutôt "coûteux". Comme toujours, il s'agit de concevoir un système robuste dès le départ afin de permettre une croissance importante.