Godzil (./16) :
pour l'ethernet/TCP/IP la on a vraiment du gaspillage de BP parcequ'il faut envoyer la meme information a tout le monde, soit en direct (chaque machine envois a tous les clients) soit au client maitre qui redistribue a tout le monde

Ethernet et TCP/IP supportent le multicast/broadcast, c'est sur Internet que ça pose problème (malheureusement).

Godzil (./16) :
Pour moi le point faible est la fiabilité des infos recus, il est un peu plus compliqué d'indiquer qu'un packet est foireux, enfin il y a bien certains moyens, mais ca complexifie la chose.

Comme tu dis, les codes correcteurs d'erreur sont faits pour ça, je pense pas que ça pose un vrai problème sur un lien local qui fait quelques mètres au total. La synchro et l'éventuelle gestion des collisions me semble plus complexes.

Godzil (./16) :
Il ya probablement plein de type de jeu auquel je ne pense pas et qui peuvent marcher en mode async, mais la je ne vois pas..

Tu as pourtant pas mal de jeux en ligne qui fonctionnent comme ça, vu que ça fait économiser beaucoup de bande passante et permet de tolérer la latence.
Mais c'est vrai qu'éviter les désynchros n'est pas simple. Sur PC par exemple c'est un vrai sujet, notamment parce qu'il y a plein de différences possibles entre les machines (un CPU Intel et un CPU AMD ne donnent pas exactement les mêmes résultats pour les calculs en virgule flottante, par exemple), et énormément de machins asynchrones qui tournent en parallèle. Sur la Lynx c'est beaucoup plus simple, mais il y a des choses qui restent asynchrones (par exemple, deux machines n'auront pas forcément le même nombre de VSYNC entre deux trames).

Pour ce qui est des méthodes d'accès, ce lien est pas inintéressant :
https://en.wikipedia.org/wiki/Channel_access_method