Discussion :

[yahiko]

Finalement, la discussion suite à l'article est presque plus instructive (notamment sur certains intervenants) que l'article en lui-même.

Je ne sais pas si certains ont remarqué, mais il ne s'agit que d'un premier article introductif où l'auteur mentionne dans sa conclusion qu'il expliquera le comment par la suite.

De plus, certains (les même que précédemment) devraient avoir la bienséance et la modestie de lire réellement un article en entier au lieu de le "survoler rapidement" avant de poser des questions ou des affirmations qui peuvent être soit hors-sujet, soit être expliquées dans les prochains articles de cette série que Bousk fait l'effort de traduire.

A bon entendeur.

[Neckara]

@yahiko : J'ai comme l'impression que tu parles de moi .

Pour ce qui est la modestie, je n'ai jamais eu la prétention d'en savoir plus que l'auteur, je l'ai déjà dit.
Tout ce que j'ai fait, c'est poser des questions sur certains points et affirmer que pour le choix "UDP ou TCP", un débutant ferait mieux de s'orienter, dans un premier temps, vers du TCP :

S'il veut faire son jeu, bah il utilisera Unity, Raknet, ou TCP. Il est pas aussi naif.

Bon, je reconnais que je me suis peut-être mal exprimé et que j'aurais dû faire des réponses plus courtes en allant à l'essentiel pour gagner en clarté.

de cette série que Bousk fait l'effort de traduire

Il n'a jamais été question de critiquer le travail de traduction de Bousk et je lui suis très reconnaissant pour ce travail.
Cependant, cela ne nous empêche pas d'avoir un regard critique et de poser des questions sur l'article.

Alors oui, on peut avoir tord, je n'ai pas la prétention de détenir la vérité absolue. C'est pour cela qu'on échange et qu'on débat à coups d'arguments.

qui peuvent […] être expliquées dans les prochains articles

Difficile de le savoir avant de les avoir lus.

de lire réellement un article en entier au lieu de le "survoler rapidement"

Il y a "survoler" et "survoler". De plus, entre deux réponses, je prend la peine de relire l'article pour être bien sûr.
Certains éléments peuvent effectivement nous échapper à une première lecture, cela peut arriver.

EDIT : d'ailleurs, après relecture, je parlais de l'article anglais dont le lien est dans l'article : http://www.isoc.org/INET97/proceedings/F3/F3_1.HTM

Sinon, si tu as des choses à me reprocher ou à reprocher à un autre, tu peux aussi le faire en privé. Ne te gêne pas de me contacter par e-mail, je suis toujours réceptif aux critiques. Mais là, à part tenter de relancer un débat clos et lancer un troll par la même occasion, je vois mal l'intérêt de ton intervention.

avant de poser des questions ou des affirmations qui peuvent être soit hors-sujet

On ne va tout de même pas se lancer dans un débat "cette question/affirmation était HS" au risque de relancer le débat sur la question/affirmation elle-même.

Je ne comprends pas ce qui semble vous énerver tant. Je n'ai jamais dit que l'article avait tord, qu'il était nul, que la traduction était mal faite ou qu'on aurait jamais dû traduire cet article, au contraire, j'aime plutôt bien cet article.

[Kannagi]

Pour ma part Neckara mon avis qui est je pense assez 'neutre' (enfin vu que j'ai pas de connaissance pratique sur les jeux en ligne).
Pour ma part ce genre article , je le prend pour argent comptant si un pro dans l'industrie qui a de l’expérience dans le domaine me conseille UDP , je ferait de UDP autant prendre les bonnes pratiques , j'ai commencé en tant amateur complet quand j’étais étudiant je connais aucune bonne technique fait pour les débutants, que ça soit dans les programmation des graphisme ou dans l'architecture du jeu en lui même donc maintenant je regarderait directement la bonne méthode.
Après si on fait un jeu en ligne j'imagine que on sort du cadre du débutant (sauf si on fait un pong en ligne je vous l'accorde).

Enfin dommage pour moi je n'ai aucun projet actuellement pour testé UDP , mais j'y manquerai pas a l'occasion.

[MoDDiB]

Arf on ne peut pas t'envoyer de messages privés...

Je ne comprends pas ce qui semble vous énerver tant.

Dans ta manière de t'exprimer tu donnes l'impression de connaître le sujet alors que tu es débutant sans aucune expérience professionnelle dans le domaine, être critique c'est très bien mais il faut apprendre à apprendre des autres.

[Bousk]

Pour avoir une communication bilatérale avec UDP, il faut pouvoir créer 2 canaux de communication : 1 dans le sens client->serveur, un autre dans le sens serveur->client. On passe par le même socket, mais il faut que l'une et l'autre des parties puisses initier la communication. Du coup, deux canaux : un pour les informations entrantes, un pour les informations sortantes. Il faut que le serveur soit joignable "directement" par le client et le client par le serveur à tout moment. En TCP, il est uniquement nécessaire que le serveur soit joignable par le client et une fois que la connexion est établie, elle peut se faire dans les deux sens, qu'importe le routage.

Avec TCP, dès lors que la communication "sort", la réponse peut "entrer".

Je différencie les deux car les deux sont différents (M. Lapalisse n'aurait pas fait mieux :p). Avec TCP, si un client envoie un message à un serveur, alors le serveur peut répondre directement à ce client. C'est intrinsèque à la nature même de TCP. Avec UDP, un client peut envoyer un message à un serveur et le serveur peut ne pas être en mesure de lui répondre si le client n'est pas accessible directement (par exemple, car derrière un routeur). Et dans cette configuration, avoir un serveur relay (suggestion que tu as faite), je ne vois pas du tout ce que cela change. Ma question reste donc toujours en suspens...

Une dernière fois, parce qu'on dirait que je parle dans le vent... tu racontes n'importe quoi.
Et je voudrais pas que quelqu'un qui tombe sur ce sujet croie ce que tu racontes.

UDP ou TCP sont strictement identiques, ce ne sont que des surcouches d'IP.
Quand tu fais une connexion TCP, tu n'ouvres pas ton port sur ton client que je sache ? D'ailleurs tu te moques bien du port dans 99% des cas. Qui se fatigue à utiliser bind pour un socket TCP ?! Non, on utilise directement connect. Sais-tu au moins que ton socket TCP a tout de même un port ?!
UDP ne nécessite pas plus que le port client soit ouvert pour envoyer des paquets.

Quand ton routeur envoit un paquet, d'ailleurs il utilisera son propre port possiblement différent de celui de l'application, fera un mapping entre le port/ip local de l'application et le port qu'il utilisera, il autorise temporairement ce qui va rentrer sur ce port, en guise de réponse, et saura où renvoyer la réponse s'il y en a une grâce à son mapping. Sinon internet aurait bien du mal à fonctionner! Tu as ouvert le port 80 TCP sur ton routeur ? Et l'a redirigé vers ton PC ? Et que se passe-t-il si tu as plusieurs PC ? Pourtant tu as bien accès à des pages webs non ?!?!! Et ce sur toutes les machines de ton réseau local!
La technique de Nat traversal ne fait qu'exploiter ce fonctionnement.
Et un jeu qui utilise UDP poussera ce fonctionnement pour faire un mode connecté virtuel. Qui est d'ailleurs exactement ce que fait TCP puisque, il semble falloir le rappeler, TCP comme UDP ne font que utiliser IP.
Encore faut-il connaître ce procédé ou bien attendre la suite des articles...

[Neckara]

Arf on ne peut pas t'envoyer de messages privés...

Et je ne peux pas non plus en envoyer.

À gauche de mon post, il faut cliquer sur "Neckara" puis sur "envoyer un e-mail".

Dans ta manière de t'exprimer tu donnes l'impression de connaître le sujet alors que tu es débutant sans aucune expérience professionnelle dans le domaine

Je n'ai certes pas d'expérience professionnel dans le jeu vidéo, mais je ne suis pas non plus un débutant complet en programmation.
Et de part mon expérience amateur, mes cours et mes lectures, j'ai quelques connaissances en réseau, en embarqué, …

Je sais comment fonctionne TCP, je sais comment fonctionne SSL, bien que je n'en connaisse pas toutes les petites nuances et que je n'ai pas en tête les benchmark de leurs performances. Ce n'est pas parce que je ne suis pas expert en jeu vidéo que je ne connais rien à quelques matières "transversales".

À noter aussi que je parle de développement amateur/débutant qui a des problématiques qui lui sont propres et dont l'expérience professionnel ne peut pas toujours appréhender.
Cela fait quelques années que je développe en amateur, et je sais que si un débutant commence, avant toute chose, par créer sa propre surcouche UDP avec acquittement, etc. Ceci sera généralement peu motivant, bogué et ne facilitera pas le développement et les tests.

Longue argumentation :

Pour l'optimisation, on commence toujours par le plus simple, on recherche les zones critique et on essaye d'optimiser, toujours en faisant des benchmark. Par exemple, on commence toujours par de l'optimisation sur un cœur/thread (ou copro), c'est là où on peut gagner des facteurs 1000 quand passer sur plusieurs cœurs/threads empêche certaines de ces optimisations et permet de gagner un facteur maximum de 8 si on a que 8 flux d'exécution. On est pragmatique et on ne fait pas d'optimisations prématurées qui peut être inutile, source de bogue, d'illisibilité et d'inmaintenabilité du code. Tout bon professionnel vous le dira. Même les plus expérimentés font des benchmark, quand bien même ils se doutent du résultat. Après tout le monde ne le fait pas forcément, mais la bonne pratique conseillerait de le faire.
À moins d'être professionnel et d'avoir tout une équipe à sa disposition, on ne s'inquiète pas de gagner 0,1% en temps d'exécution avant d'avoir un premier prototype fonctionnel.

Pour tester, c'est la même chose, on commence par des tests unitaires, tester déjà si la classe se comporte correctement en s'affranchissant du reste, on ne teste jamais directement en production, on a d'abord plusieurs niveaux de tests avant d'en arriver là. Le but de tester en local, c'est justement de s'affranchir des contraintes liés au réseau pour tester les autres composants. De ne tester qu'une chose à la fois. Ainsi quand on testera en "conditions réel", on cherchera d'abord du côté du réseau (port fermé ? paquet qui se perd ? paquets arrivant dans le désordre ?).
Et cela permet, même pour un débutant de gagner en temps de débogue et d'acquérir de bonnes pratiques. C'est plus simple de déboguer quand on sait, à priori, où peut se trouver le bogue plutôt que de se lancer dans une chasse au trésor.
De plus, les tests de "bases" sont fait pour être exécuté le plus régulièrement possible, idéalement à chaque compilation. Ainsi, si on introduit un bogue, on pourra espérer le détecter le plus rapidement possible, ce qui facilite le débogue et permet un gain d'argent dans le milieu professionnel.

Je n'invente rien, ce sont des bonnes pratiques qui ne sont pas propres uniquement aux jeux vidéos.

C'est pour cela que je recommande de commencer par du TCP pour les débutants, pour faciliter les tests et débogues, pour aboutir à un prototype plus rapidement, et ne pas se lancer dans quelque chose de complexe dès le début.
Dès qu'on a un prototype et qu'on a un début de logique de jeux on peut refactoriser le module réseau pour le faire en UDP avec éventuellement quelques contrôles (acquittement, …). Si l'architecture est bien pensée, cela ne coûte presque rien. Ainsi, on peut même avoir un choix entre TCP ou UDP ce qui peut être utile pour certains tests. La version TCP peut alors servir de référence pour tester la version UDP, si la version UDP est plus lente que la version TCP, on peut en déduire qu'il y a un problème dans notre surcouche UDP. Non seulement on arrive à un prototype plus rapidement mais, en plus, on gagne en temps de débogue.
On peut même aller plus loin et au lieu de faire du TCP, si cela dérange vraiment, on peut partir sur des tubes nommés, cela prend quelques minutes et on pourra tester sans aucune contrainte réseau avant de le remplacer par de l'UDP le moment venu. Donc on peut commencer à avoir un prototype sans encore savoir créer des sockets.
On peut approcher cela du TDD : on fait d'abord en sorte que "ça marche" (= passe les tests) en allant au plus "rapide"/"fainéant" avec éventuellement des modules bidons, puis on améliore.
On peut aussi penser à l'agilité, on commence par un prototype fonctionnel qu'on améliore progressivement.

Ce que je veux dire, c'est que le choix TCP vs UDP final n'est pas forcément le choix à prendre en début de développement, on peut même commencer par des tubes nommés tout bête. L'important, c'est de faciliter le débogue et le développement.
Quand on écrit un module A dépendant un module B, on ne va pas attendre d'avoir fini le module B avant de commencer à tester le module A. On va donc avoir un module B' tout bête, non-optimal, dans un premier temps pour tester A. Puis qui sait, au fur et à mesure du développement, on peut s’apercevoir que le module B n'est finalement pas optimal/adapté à notre problématique et on décidera d'avoir un module B''.
Puis finalement, on peut finir avec un module B''' qui peut encore être amélioré, mais on considère le gain gain/coût trop faible.

En bref, des surprises peuvent arriver. À moins bien sûr d'utiliser une méthode non-agile comme le cycle en V mais cela me semble, ce n'est que mon avis, légèrement suicidaire pour des débutants.

être critique c'est très bien mais il faut apprendre à apprendre des autres.

Je n'ai jamais eu la prétention de donner des leçons à des professionnels.

J'apprends des autres, sinon je ne serais pas ici en train d'échanger avec vous et je n'aurais pas lu cet article.

[Bousk]

TCP permet surtout de camoufler tout les échanges et de faire croire à l'utilisation d'un stream, d'un fichier.

Tu peux aussi le faire en UDP grâce à la fonction connect().

Je n'ai jamais utilisé connect pour un socket UDP, et cette simple citation de la page que tu link suffit à comprendre que j'ai rien raté

Si la socket sockfd est du type SOCK_DGRAM, alors serv_addr est l'adresse à laquelle les datagrammes seront envoyés par défaut, et la seule adresse depuis laquelle ils seront reçus.

connect en UDP est... (quasi)inutile. Et en tous cas ne répond pas du tout au problème et à ma phrase que tu cites.

[Neckara]

connect en UDP est... (quasi)inutile. Et en tous cas ne répond pas du tout […] à ma phrase que tu cites.

Avec connect, tu vas pouvoir utiliser les fonctions read, write, fdopen, …
Bref, de le manipuler avec la même interface qu'un socket TCP sans avoir besoin de préciser (et donc de stocker toi-même) à chaque fois le port et l'adresse.

Tu fais donc croire à l'utilisation d'un fichier, en version peu fiable, certes.

[MoDDiB]

Je n'ai jamais eu la prétention de donner des leçons à des professionnels.
J'apprends des autres, sinon je ne serais pas ici en train d'échanger avec vous et je n'aurais pas lu cet article.

Oui clairement, c'est plutôt une mauvaise interprétation de tes propos

À noter aussi que je parle de développement amateur/débutant qui a des problématiques qui lui sont propres et dont l'expérience professionnel ne peut pas toujours appréhender.
Cela fait quelques années que je développe en amateur, et je sais que si un débutant commence, avant toute chose, par créer sa propre surcouche UDP avec acquittement, etc.

On est bien d'accord, et même pour un professionnel : il existe déjà des midlewares se chargeant de cette surcouche udp, alors à moins d'être dans une grosse boîte de jeux vidéo l'intérêt est plutôt limité.

[Neckara]

On est bien d'accord, et même pour un professionnel : il existe déjà des midlewares se chargeant de cette surcouche udp, alors à moins d'être dans une grosse boîte de jeux vidéo l'intérêt est plutôt limité.

Malheureusement, beaucoup de débutants n'hésitent pas à réinventer la roue pour diverses raisons : méconnaissance de l'existant, pour apprendre, pour s'amuser, pour s'approprier le code, pour ne pas devoir utiliser une autre bibliothèque, parce ce sera "plus rapide" que de recherche/apprendre à utiliser l'existant, …

Mais si on donne un choix "TCP ou UDP", le premier réflexe de certains débutants est de créer sa propre surcouche. Si on lui donne le choix "TCP ou surcouche de UDP", avec un peu de chance, il va regarder l'existant, mais s'il voit trop de choix, il y a des chances qu'il ne sache quoi choisir et finalement décide de faire sa propre surcouche pour s'éviter de choisir.

De plus, les amateurs n'ont pas forcément les même objectifs ni les mêmes contraintes qu'un professionnel. S'il veut s'amuser et apprendre/approfondir ses cours, il peut s'amuser à écrire sa propre surcouche, mais on est d'accord que ce n'est pas la meilleure solution pour sortir un jeu.

J'ai d'ailleurs repéré un post assez intéressant : http://www.developpez.net/forums/d68...n/#post4016031

[yahiko]

Malheureusement, beaucoup de débutants n'hésitent pas à réinventer la roue pour diverses raisons : méconnaissance de l'existant, pour apprendre, pour s'amuser, pour s'approprier le code, pour ne pas devoir utiliser une autre bibliothèque, parce ce sera "plus rapide" que de recherche/apprendre à utiliser l'existant, …

Ca me rassure car je ne comprenais pas pourquoi tu cherchais à réinventer les tests unitaires en C++.

[ElTotor]

Une dernière fois, parce qu'on dirait que je parle dans le vent... tu racontes n'importe quoi.
Et je voudrais pas que quelqu'un qui tombe sur ce sujet croie ce que tu racontes.

UDP ou TCP sont strictement identiques, ce ne sont que des surcouches d'IP.
Quand tu fais une connexion TCP, tu n'ouvres pas ton port sur ton client que je sache ? D'ailleurs tu te moques bien du port dans 99% des cas. Qui se fatigue à utiliser bind pour un socket TCP ?! Non, on utilise directement connect. Sais-tu au moins que ton socket TCP a tout de même un port ?!
UDP ne nécessite pas plus que le port client soit ouvert pour envoyer des paquets.

Quand ton routeur envoit un paquet, d'ailleurs il utilisera son propre port possiblement différent de celui de l'application, fera un mapping entre le port/ip local de l'application et le port qu'il utilisera, il autorise temporairement ce qui va rentrer sur ce port, en guise de réponse, et saura où renvoyer la réponse s'il y en a une grâce à son mapping. Sinon internet aurait bien du mal à fonctionner! Tu as ouvert le port 80 TCP sur ton routeur ? Et l'a redirigé vers ton PC ? Et que se passe-t-il si tu as plusieurs PC ? Pourtant tu as bien accès à des pages webs non ?!?!! Et ce sur toutes les machines de ton réseau local!
La technique de Nat traversal ne fait qu'exploiter ce fonctionnement.
Et un jeu qui utilise UDP poussera ce fonctionnement pour faire un mode connecté virtuel. Qui est d'ailleurs exactement ce que fait TCP puisque, il semble falloir le rappeler, TCP comme UDP ne font que utiliser IP.
Encore faut-il connaître ce procédé ou bien attendre la suite des articles...

Non, tu ne parles pas dans le vent, mais tu persistes aussi dans l'erreur. UDP et TCP sont des surcouches d'IP. Nous sommes d'accord. Est-ce qu'un routeur à besoin d'accéder à ces couches ou peut-il se contenter de la couche IP ? La réponse est : IP ne gérant pas les ports, le mapping dont tu parles nécessite forcément un accès à la couche UDP/TCP (pourquoi le NAT classique ne fonctionne pas avec IPSec ?? Car la couche 4 n'est pas disponible !). Et là, les choses se gâtent, car si les deux couches ont toutes deux la notion de port avec une signification identique, la manière dont ils sont traités peuvent être radicalement différente. Si je sépare les deux protocoles UDP et TCP, c'est parce que d'une part, les deux existent, et d'autre part parce que j'ai déjà vu un routeur faire le mapping dans le cas du TCP, mais pas dans le cas de l'UDP ! (ok routeur de merde, changer le routeur. C'est d'ailleurs ce qui a été fait ^^)

Et donc, mon affirmation initiale consistant à dire qu'avec TCP, si le client envoie une réponse avec succès, alors il sait que le serveur peut lui répondre, tandis qu'avec UDP il ne le saura pas reste vrai. Et dans le cas d'UDP, le client saura juste qu'il n'a pas de réponse. il ne saura pas si la requête a bien été reçu ou non ou si le problème ne concerne que la réponse du serveur qui ne lui ait pas parvenu.

Maintenant, se faire limite traiter de "débile" avec le pseudo-cours sur le fonctionnement du port mapping pour les nuls et lire que je dis n'importe quoi juste parce qu'on ne se comprend pas, j'apprécie. J'arrête là pour cette discussion stérile.

[Neckara]

Ca me rassure car je ne comprenais pas pourquoi tu cherchais à réinventer les tests unitaires en C++.

Tu es vraiment là juste pour troller ?
Ce n'est pas vraiment l'endroit pour en parler et j'y ai déjà répondu sur le sujet dédié où je serais très heureux de vous répondre à nouveau.

Sinon, si tu as des arguments sur le sujet actuel autre que des attaques ad hominem, je serais heureux de les entendre.

[yahiko]

Non, je veux pas troller. Maintenant tu tend le bâton pour te faire battre. C'est trop tentant
Allez sans rancune.

EDIT : Attaque ad hominem ? Non, aucunement ou alors faudra me dire où.

[DonQuiche]

@Neckara
Tout ce que tu dis n'est pas faux, surtout lorsque tu insistes sur le fait d'écrire d'abord un proto avant de tirer des plans sur la comète. Mais :

a) Certaines optimisations ne peuvent pas être faîtes sur le tard. Convertir ton jeu de TCP en UDP c'est un très large effort de réécriture, et un gaspillage du travail réalisé jusque là. De même que tu ne peux souvent pas paralléliser sur le tard parce qu'il aurait fallu utiliser des structures de données différentes, des algorithmes différents, ajouter des vérifications à mesure que tu écrivais ton code, etc. Dans ce second cas ce n'est pas seulement coûteux, c'est dangereux car tu risques d'introduire des pelletées de bugs qui auraient été évités avec une mise en œuvre au fil du développement quand tous les détails des interactions entre états étaient frais dans les mémoires.

b) Les paramètres qui déterminent le choix entre UDP et TCP sont complètement connus en début de projet. C'est une question de latence réseau et tu connais les marges de celles-ci à l'avance. Pour l'occident tu vas par exemple utiliser un objectif d'un jeu jouable sous 150-200ms de latence, davantage si tu vises des régions plus pauvres, latence doublée en cas de serveur entre les joueurs et en incluant les pics de latence du fait des renvois de paquets de perdus. Selon la sensibilité de ton gameplay a une telle latence tu sauras d'avance si tu auras besoin de TCP ou UDP.

[Neckara]

Après ce sont des bonnes pratiques, mais après, chaque projet est unique, a ses propres contraintes, et cela est loin de se résumer en un seul métier.

Convertir ton jeu de TCP en UDP c'est un très large effort de réécriture, et un gaspillage du travail réalisé jusque là.

Pour moi, c'est juste une classe à changer si l'architecture a bien été pensée. Si le couplage et la cohérence du code sont respectivement faible et forte, cela ne devrait théoriquement pas trop poser de problèmes. Je peux néanmoins me tromper et cela peut aussi dépendre du projet.
Et, dans le cas où ajouter UDP est peu coûteux, ce n'est pas du gaspillage car j'estime que le TCP aura permis un développement plus rapide et qu'à la fin, nous pourrons proposer deux protocoles ce qui peut avoir son utilité (test, réutilisable pour un autre jeu, …).

Parallélisation :

De même que tu ne peux souvent pas paralléliser sur le tard parce qu'il aurait fallu utiliser des structures de données différentes, des algorithmes différents, ajouter des vérifications à mesure que tu écrivais ton code

Commencer par du parallèle, pour un débutant, cela va être sûrement un mauvais découpage, des bugs affreux et incompréhensible, des accès simultanés, des dead lock, … donc c'est préjudiciable d'autant plus que très souvent, il peut s'en passer.

Ensuite, comment vas-tu savoir que ta version parallèle sera plus performante que ta version séquentielle ? On ne peut pas vraiment décider de cela au petit bonheur la chance. Paralléliser peut faire sauter des optimisations, les synchronisations peuvent avoir un coût, etc.
De plus, même si la version parallèle est plus performante que la séquentielle, en a-t-on vraiment besoin ?
Elle est plus performante sur ton 8cœurs, mais l'est-il aussi sur un 2cœurs, … ?
Paralléliser, oui mais comment ? Pipeline ? TBB ? OpenMP ? Des threads en dur ?
Paralléliser, oui mais quoi ? Une boucle ? Un algorithme ? Exécuter deux algorithmes en parallèle ?
Et surtout, combien de threads ? Un nombre fixé ? Évoluant en fonction du poste de l'utilisateur ?
Cela me semble très difficile de choisir sans avoir une très bonne expérience, avoir des benchmark d'autres jeux, …

Après, ce n'est pas parce qu'on fait deux threads, qu'on fait déjà de l'optimisation. Mais faire deux threads parce que ce sera "plus performant" qu'une version séquentielle est, à mon avis, une erreur (moyennant quelques cas très triviaux).
Si cela a vraiment du sens d'avoir deux threads ou que ce soit "plus simple"* de faire deux threads qu'une version séquentielle, pourquoi pas, mais il faut vraiment que ce soit cohérent et réfléchit.
Mais quand on voudra optimiser l'un des threads, on commencera par l'optimiser sur un cœur, … avant de songer à le découper en plusieurs theads.

* il faut aussi que l'estimation de la difficulté ne soit pas trop éloignée de la réalité.


Bon, pour le cas de traitement d'images lourd, on sait pertinemment que le CPU n'est pas adapté et qu'on va le dans une version parallèle sur GPU. Après, on ne va pas non-plus chercher l'optimisation maximale, c'est presque impossible à atteindre, d'autant plus sur des architectures différentes, donc on s'arrête dès qu'on a des résultats satisfaisant.


Et enfin, il n'est pas nécessaire d'attendre d'avoir un prototype complètement fonctionnel pour faire des tests et réécrire des modules.
On peut aussi récupérer les benchmark que des personnes ont fait à notre place, on peut essayer de simuler le fonctionnement pour tenter de comparer différentes solutions mais aussi de s'y familiariser. Après avec l'expérience, on peut avoir quelques à priori, mais rien de 100% sûr.
Alors oui, il peut commencer avec 10 threads, mais il n'aura aucune garantie que ce soit la solution optimale ou la solution la plus simple.

Si paralléliser introduit trop de synchronisations, on peut aussi se poser la question de la cohérence du découpage.

Mais bon, c'est loin d'être trivial et je ne pense pas qu'on puisse demander à un débutant d'avoir l'expérience nécessaire pour déterminer s'il a besoin d'un thread ou deux. Donc autant qu'il aille au plus simple quitte à devoir réécrire une partie de son code au lieu de se planter directement dans un mur.


Bon en comparaison, le choix UDP/TCP est infiniment plus simple .

Les paramètres qui déterminent le choix entre UDP et TCP sont complètement connus en début de projet. C'est une question de latence réseau et tu connais les marges de celles-ci à l'avance (pour l'occident tu vas par exemple utiliser un objectif d'un jeu jouable sous 150-200ms de latence, davantage si tu vises des régions plus pauvres). Pour chaque état tu sais si tu auras besoin de TCP ou UDP en fonction de l'impact de la latence.

Hors FPS, les jeux d'actions peuvent nécessiter des latences suffisamment faible pour se contenter de TCP.
Le TCP peut donc "suffire". Par contre, est-ce qu'il va tenir la charge des connectés ? Est-ce qu'on a fait une mauvaise estimation pour la latence ?
Un débutant peut se tromper sur l'estimation des paramètres, et finalement décider de passer en UDP. Mais personnellement, je préfère cela que de se plonger tête baissé dans UDP "parce que c'est mieux". C'est une erreur, mais c'est aussi une expérience qui peut être valorisante.
Il n'aura pas pris de l'UDP "parce qu'on dit que c'est mieux", mais sa décision s'inscrit dans une démarche et il a compris pourquoi il a fait ce choix. Il aura aussi montré qu'il est capable de refactorer son code, bref, ce n'est pas si négatif que cela.

Si sait qu'il a des contraintes en latence, il peut commencer par du TCP, juste un serveur "Hello Word" pour tester la latence puis faire de même avec de l'UDP. Cela ne coûte presque rien et c'est très instructif. (Par contre il aura bien commencé par du TCP na ! Je reconnais que cet argument est un peu abusé et ressemble plus à une pirouette de ma part pour retomber sur mes pattes).
Après, il faut tester. Si notre serveur maison a une latence moyenne de 200ms on aura plus de facilité à passer par de l'UDP par exemple.
Et il aura pas attendu d'avoir un prototype complet avant de commencer à tester.

Après, chaque projet est unique ainsi que ses objectifs.
Si le but est de faire un FPS en LAN, le TCP devrait passer (?). Si le but est de démontrer ses compétences (dont réseau), il va peut-être faire une surcouche UDP. Si le but, c'est juste de s'amuser sans forcément une volonté de distribuer le jeu, il peut choisir ce qui l'arrange.
Il y a la théorie et de l'autre la pratique. On ne peut pas énumérer tous les cas et les exceptions possibles.

Après, pour les professionnels, je les considère assez grand pour savoir ce qu'ils font sans compter que d'autres paramètres peuvent entrer en jeu (coûts, existant, pérennité, …) je n'ai donc pas la prétention de pouvoir leur donner des conseils ni même de leur apprendre leur métier.

[DonQuiche]

Pour moi, c'est juste une classe à changer si l'architecture a bien été pensée.

Mais non puisque avec UDP tu veux traiter immédiatement les données reçues dans le désordre et dont il manque parfois des bouts, qui arriveront peut-être ou non plus tard, et sans avoir le luxe de pouvoir attendre des avis de réception !

Du coup tu as différents modèles possibles avec UDP :
* Des états pour lesquels on envoie les valeurs en continu sans se soucier de savoir si elles ont été reçues. Le destinataire se contentera de la valeur la plus récente reçue. Exemple : la position.
* Des états pour lesquels la source exigera une confirmation (ack) au destinataire. Et on pourra ensuite attendre ou non la confirmation. Exemple : l'achat d'un objet.
* Des états pour lesquels on laissera le destinataire éventuellement demander confirmation en cas d'anomalie. Exemple : la mort d'un joueur, que le destinataire soupçonnera s'il ne reçoit plus de position.

Donc, non, ce n'est pas du tout le même code et tu ne dois pas prendre cette décision sur le tard !

Le TCP peut donc "suffire". Par contre, est-ce qu'il va tenir la charge des connectés ? Est-ce qu'on a fait une mauvaise estimation pour la latence ?
Un débutant peut se tromper sur l'estimation des paramètres, et finalement décider de passer en UDP. Mais personnellement, je préfère cela que de se plonger tête baissé dans UDP "parce que c'est mieux". C'est une erreur, mais c'est aussi une expérience qui peut être valorisante.

Si le programmeur ne sait pas, alors la bonne réponse est le prototypage, pas d'attendre la deadline pour voir s'il faudra tout réécrire !

Tu fais un fps ? Et bien tu passes quatre heure à programmer un cylindre en mouvement représentant un joueur qui se déplace devant ton nez, et à chaque clic tu programmes un callback pour déclencher le tir 200ms plus tard à cette position (400ms si les mouvements doivent passer par un serveur). Et tu vois ce que ça donne.

Ensuite, comment vas-tu savoir que ta version parallèle sera plus performante que ta version séquentielle ? On ne peut pas vraiment décider de cela au petit bonheur la chance. Paralléliser peut faire sauter des optimisations, les synchronisations peuvent avoir un coût, etc.

En général ce n'est pas un problème : dans la majorité des bons modèles les données sont isolées, spécifiques à chaque thread, avec peu de communication entre threads, si bien que le coût de la synchro est négligeable et le gain potentiel substantiel et déterminé à l'avance. Par exemple si tu regardes la plupart des moteurs aujourd'hui, le thread gameplay n'échange qu'une fois par frame avec les threads de rendu et de gameplay. Le seul coût restant ce sont les effets de cache dont la magnitude est connue. Par ailleurs ce genre de modèle est très simple à mettre en oeuvre pour peu que tu connaisses ces questions.

En revanche c'est sûr que si tu tentes de paralléliser sur le tard, depuis un code monothread, au niveau d'une petite boucle, là tu vas devoir ajouter des pelletées de synchronisations et tu produiras un machin peu performant et bogué jusqu'à l'os.

Enfin si tu es malgré tout dans un des rares cas où tu ne sais pas si une opération devra être parallélisée, il y a le prototypage pour ça. Mais la parallélisation n'est pas quelque chose qu'on peut décider sur le tard.

Mais quand on voudra optimiser l'un des threads, on commencera par l'optimiser sur un cœur, … avant de songer à le découper en plusieurs theads.

Optimiser ça veut dire foutre en l'air ton code et le rendre difficilement maintenable. Dans bien des cas tu peux obtenir très simplement un gain beaucoup plus conséquent avec plusieurs threads. Le multithreading c'est souvent simple et sans danger si tu sais ce que tu fais et que ton architecture a été prévue en conséquence. La clé ce sont des données isolées, dont un seul thread est propriétaire, par opposition aux données partagées. Mais pour ça il faut une architecture conçue dès le début pour permettre et prouver cette contrainte.

Commencer par du parallèle, pour un débutant, cela va être sûrement un mauvais découpage, des bugs affreux et incompréhensible, des accès simultanés, des dead lock, … donc c'est préjudiciable d'autant plus que très souvent, il peut s'en passer.

Qui a dit que nous parlions des débutants ? Dans la vie réelle le mec qui va coder le code réseau n'est pas forcément un expert réseau. C'est peut-être simplement un type de l'équipe qui prend la main parce que son prédécesseur a démissionné, ou parce que l'équipe en place est déjà en sur-effectif sur ce jeu, ou parce que ça l'intéresse et qu'il a la confiance de ton supérieur, ou parce qu'il est pote avec Robert qui dirige l'équipe réseau. Les organisations humaines sont avant tout humaines.

[Neckara]

Mais non puisque les données sont parfois perdues en route avec UDP, qu'elles arrivent dans le désordre, et qu'on ne veut pas attendre de les réordonner ni attendre de confirmation !

Mais cela c'est géré dans le module réseau non ?

Du coup tu as différents modèles possibles avec UDP :
* Des états pour lesquels on envoie les valeurs en continu sans se soucier de savoir si elles ont été reçues. Le destinataire se contentera de la valeur la plus récente reçue. Exemple : la position.
* Des états pour lesquels la source exigera une confirmation (ack) au destinataire. Et on pourra ensuite attendre ou non la confirmation. Exemple : l'achat d'un objet.
* Des états pour lesquels on laissera le destinataire éventuellement demander confirmation en cas d'anomalie. Exemple : la mort d'un joueur, que le destinataire soupçonnera s'il ne reçoit plus de position.

Cela tu peux le décider au début, que tu choisisses TCP ou UDP (?)
Le tout c'est de prévoir de passage à l'UDP/surcouche UDP si on est en TCP et qu'on est pas sûr à 100%.

Au lieu d'avoir 2 fonctions d'envoi (sync, async), pourquoi ne pas en faire "plus" (?).

• pour des données qui se périment (date ou si plus récente disponible) ;
• pour des données qui demandent un acquittement (async et sync) ;
• pour demander confirmation (?).

Mais là, je reconnais qu'il faudrait l'implémenter pour être sûr. Mais je pense que cela pourrait au moins réduire la "casse".

Si le programmeur ne sait pas, alors la bonne réponse est le prototypage, pas d'attendre la deadline pour voir s'il faudra tout réécrire !

Tu fais un fps ? Et bien tu passes quatre heure à programmer un cylindre en mouvement représentant un joueur qui se déplace devant ton nez, et à chaque clic tu programmes un callback pour déclencher le tir 200ms plus tard à cette position (400ms si les mouvements doivent passer par un serveur). Et tu vois ce que ça donne.

Justement, donc tester, c'est ce que je disais.

Par exemple si tu regardes la plupart des moteurs aujourd'hui, le thread gameplay n'échange qu'une fois par frame avec les threads de rendu et de gameplay (?).

En gros, on copie le "modèle gameplay" dans le "modèle vue" et la vue fais l'affichage (?).

En revanche c'est sûr que si tu tentes de paralléliser sur le tard, depuis un code monothread, au niveau d'une petite boucle, là tu vas devoir ajouter des pelletées de synchronisations et tu produiras un machin peu performant et bogué jusqu'à l'os.

Cela dépend fortement de la boucle et de la manière utilisée pour paralléliser.
Généralement, tu vas même complètement réécrire la boucle ou changer d'algorithme dans certains cas.

Enfin si tu es malgré tout dans un des rares cas où tu ne sais pas si une opération devra être parallélisée, il y a le prototypage pour ça. Mais la parallélisation n'est pas quelque chose qu'on peut décider sur le tard.

On attend pas d'avoir fini avant de faire des tests. C'est ce que je dis, on teste, mais pour tester une implémentation, il faut au moins commencer à l'écrire, donc "commencer par elle" en somme et vérifier si elle convient. Mais pour cela, on a pas nécessairement besoin des autres modules ni même d'avoir fini d'implémenter le module, donc oui, un prototype en somme.

Le multithreading c'est souvent simple et sans danger si tu sais ce que tu fais

C'est justement souvent cela le problème. .

Après pour les threads, le gain va aussi varier selon l'architecture selon s'il a 1, 2 ou 8 cœurs.
Et comme je l'ai dit, si c'est cohérent d'avoir plusieurs threads, pourquoi pas.

Mais il n'y a pas de garantie d'avoir nécessairement des gains, pour un pong par exemple, on peut se contenter d'un seul thread et ne pas s'enquiquiner avec plusieurs threads.

Après oui, je comprend ton argument, on sait que parfois on a besoin de X threads, donc on va les prévoir. Si on en a pas réellement besoin, tant pis, ce n'est pas si grave. Par contre si on en a besoin, c'est tout gagné. Par contre, à partir de quel niveau on peut envisager de faire plusieurs threads ?

Optimiser ça veut dire foutre en l'air ton code et le rendre difficilement maintenable.

Oui et même parfois non portable (peut-être pas dans le jv par contre).
Mais, on peut faire des petites optimisations au niveau de la complexité et des copies qui ne mangent parfois pas de pain.

Qui a dit que nous parlions des débutants ?

Surtout moi dans mes réponses^^.

Dans la vie réelle le mec qui va coder le code réseau n'est pas forcément un expert réseau. C'est peut-être simplement un type de l'équipe qui prend la main parce que son prédécesseur a démissionné, ou parce que l'équipe en place est déjà en sur-effectif sur ce jeu, ou parce que ça l'intéresse et qu'il a la confiance de ton supérieur, ou parce qu'il est pote avec Robert qui dirige l'équipe réseau. Les organisations humaines sont avant tout humaines.

En effet, je n'avais pas pensé à cela.
Par contre, s'il n'est pas expert, n'est-il pas sage de faire des tests ou de demander confirmation pour certains choix ?


N.B. je crois qu'on est en train de partir en HS sur les threads. .
Je l'avais utilisé comme image pour illustré mes arguments, mais je crois qu'on a un peu dévié.
Je pense que j'ai compris tes arguments pour les threads.

[DonQuiche]

Mais cela c'est géré dans le module réseau non ?

Tu peux créer une couche réseau conçue pour tirer partie d'UDP (supportant des variables envoyées en continu, des variables réclamant confirmation, etc) et il sera alors facile de l'implémenter sur TCP.

En revanche tu ne peux pas prendre une couche réseau conçue pour TCP et la ré-implémenter telle quelle avec UDP : ça fonctionnera mais tu n'auras aucun gain.


Donc tu dois avoir une couche réseau UDP-friendly. Et en plus de cela il faudra que ton code gameplay en tire partie même si tu utilises en fait TCP : il faudra que ton code gameplay informe systématiquement la couche réseau de la bonne façon de traiter chaque variable (en continu, avec avis de réception, etc).

En gros si tu veux garder l'option d'une bascule ultérieure sur UDP, tu auras de toute façon fait 75% du travail nécessaire. Même si tu auras gardé TCP tout du long. Cette option sur l'avenir reste donc une lourde décision à prendre dès le début.

Justement, donc tester, c'est ce que je disais.

Sauf que toi tu recommandes d'attendre la fin en rangeant ça dans la case optimisation tardive. Au contraire j'affirme que tu dois prendre ces problématiques en compte le plus tôt possible.

En général attendra la fin pour optimiser est une bonne idée. Mais pas pour des choix qui conditionnent toute ton architecture, ceux-là doivent être précoces.

En gros, on copie le "modèle gameplay" dans le "modèle vue" et la vue fais l'affichage (?).

Non, au contraire, on sépare les deux : au lieu d'avoir un même objet partagé représentant le gameplay et le rendu, chaque entité gameplay se crée un ou plusieurs objets de rendu. Et une fois par frame on synchronise les deux threads et on informe le rendu des nouveaux objets de rendu créés et de ceux détruits, en lui transférant la propriété sur ces objets. Par la suite, toute tentative d'accès à l'objet de rendu par le thread de gameplay devient invalide.

De toute façon ça fait belle lurette que le JV a adopté des découpages en composants et qu'il existe des objets de rendu et de gameplay distincts. La seule chose qui a changé c'est qu'un tour de vis a été ajouté pour interdire au thread gameplay de manipuler un objet dont il a transféré la charge à un thread de rendu.

Si tu regardes Unity ou UE4, chaque objet gameplay a des composants de rendu, des composants de physique, etc. Après je ne sais pas si ces composants sont directement transférés ou s'ils demeurent sur le thread gameplay et transfèrent à la place un objet interne.

Cela dépend fortement de la boucle et de la manière utilisée pour paralléliser.

Ça dépend surtout des interdépendances entre états situés à l'intérieur de ta boucle. Si chaque itération travaille sur des données distinctes, aucun problème pour peu que la boucle soit assez longue. Mais si tu n'as pas conçu ton archi pour ça, si tu n'as pas divisé la conception des objets mutables en grappes mutables isolées les unes des autres, ou en petits éléments immuables/gelables, alors il y a peu de chances pour que tes donnée soient indépendantes.

Après oui, je comprend ton argument, on sait que parfois on a besoin de X threads, donc on va les prévoir. Si on en a pas réellement besoin, tant pis, ce n'est pas si grave. Par contre si on en a besoin, c'est tout gagné. Par contre, à partir de quel niveau on peut envisager de faire plusieurs threads ?

Non, je dis que de toute façon dans le JV on a rapidement besoin de cette puissance et qu'on SAIT que ça sera très rentable et simple à faire si on s'y prend dès le début, et très compliqué si on ignore ça. Au pire on va donc créer une archi qui permettra de paralléliser facilement telle ou telle tâche, même si on ne l'exploite pas dès le début.

Après il est clair que si tu sais que ton programme tournera impeccablement sur un seul thread, tu n'as pas besoin de te faire suer, ce n'est pas une religion. Et si tu as un doute -> prototypage le plus tôt possible.

C'est justement souvent cela le problème. .

Heureusement certaines choses commencent à rentrer, notamment le fait que différents threads doivent travailler sur des données isolées ou gelées. Et pour la gestion du rendez-vous et de l'échange de données, n'importe quel langage digne de ce nom offre aujourd'hui des biblios offrant des files d'attente asynchrones et primitives de synchronisation encapsulant les barrières mémoire nécessaires. Franchement n'importe quel glandu peut écrire un code sûr avec ce modèle simple et ces outils de haut niveau.

Et puis on voit des langages récents comme Rust qui ont en standard des modèles de propriété et te cracheront une erreur au visage si jamais tu partages des données mutables sans l'avoir explicitement autorisé.

[Neckara]

Après, j'ai plus une impression que c'est un choix d'architecture pour rendre le code évolutif, réutilisable, plus que pour utiliser une solution donnée.

Si on utilise TCP mais qu'on prévoit l'utilisation de UDP, on commence bien par TCP et on regarde s'il convient avant de passer à UDP, ce qui peut se passer relativement "tard". Par contre, on prévoit de pouvoir passer d'une solution à l'autre. Pour moi, cela rentre dans un choix d'architecture, plus que dans un choix TCP ou UDP. En effet, on a pas encore fait le choix final, mais on sait qu'on va en faire un. Bien que ce choix d'architecture soit en effet très important.

Pour les "optimisations", je ne dis pas qu'il faut le faire à la fin.
Quand on implémente un petit bout de code, on va le tester. De là, on va déjà pouvoir savoir s'il tient la charge ou non et prendre une décision :

• est-ce que je prend une solution plus optimale tout de suite ?
• est-ce que je prévois l'utilisation d'une autre solution ?
• est-ce que la solution convient parfaitement ?

Après, il faut aussi avoir une idée des performances requises, des machines sur-lesquelles le code va tourner.

Mais on peut parfaitement prévoir l'utilisation d'une autre solution et de garder l'actuelle pour le moment, ce n'est pas une optimisation prématurée et cela permet de continuer le prototype.
Ce qui ne l'empêche pas, au contraire, de prendre une solution plus optimale, car il voit que "ça ne passera pas" en implémentant une version simplifié dans un premier temps.

Mais oui, je suis assez d'accord avec toi.

Thread:

Après il est clair que si tu sais que ton programme tournera impeccablement sur un seul thread, tu n'as pas besoin de te faire suer, ce n'est pas une religion. Et si tu as un doute -> prototypage le plus tôt possible.

Pour des jeux 2D, on a à peu près la garantie que cela tournera sur un seul thread (?).
C'est plus pour la 3D que cela pose problème ?

Non, au contraire, on sépare les deux

Je les ai nommé un peu maladroitement.

Ce que je veux dire, c'est que à partir du thread gameplay, on va générer un arbre de tous les trucs à dessiner qu'on va ensuite donner au rendu pour qu'il dessine le tout, … (?)

Donc au final avoir 2 arbres A et B (?)
Pendant qu'on en édite A côté gameplay, on dessine B dans le thread de rendu ?
Puis on synchronise A et B en copiant A dans B ?

À moins que lors de la synchronisation, on ai un "draw" dans le thread gameplay qui permette de construire cet arbre afin qu'il soit donné dans le thread de rendu ?