Raydium 3D Game Engine

Nous avons fait qq tests avec batcox et RyLe avec la nouvelle version de test4 (celle qui propose un mini-chat dans le jeu).
Et il semble que du coté de RyLe, les pertes de paquets étaient trop importantes (à cause d'un téléchargement à coté) ce qu'il fait qu'il ne voyait pas nos messages et que le jeu semblait désynchro... (il le racontera mieux que moi )
Donc, en dehors du réseau local, UDP n'est pas suffisant
Donc.. 3éme ré-écriture du code réseau pour ajouter un cannal TCP pour les informations "importantes" ?

L'udp c'est bon pour faire du streaming, mais pas de l'envoi d'information qu'il faut à tout prix recevoir.

Peut-être qu'un mix entre l'udp et le tcp pourrait être intéressant, du style on envoi toutes les infos en udp par défaut, et style toutes les x secondes ou x milisecondes, on envoie un paquet en tcp qui permet de récupérer une éventuelle désynchro due à la non réception des paquets udp.

non ?

Je reposte à la suite de ce "vieux" topic, car le problème en question (à l'époque de test4, en l'occurence) prend maintenant une plus grande importance, avec "Ray ODE net" (l'interface Raydium/ODE qui fonctionne en réseau) qui fait un usage intensif de paquets "importants" (création/effacement d'objets, explosions, ...) lequels ne doivent pas être perdus sous peine de désynchros fatales. Plutot que de rajouter un cannal TCP par dessus l'existant, j'essaye en ce moment même de re-coder une partie du protocole TCP sur le cannal UDP existant: les accusés de réception.

Principe: Il est possible "d'expliquer" à Raydium quels sont les types de paquets "importants", et lorsque que l'application envoie l'un de ces paquets, Raydium conserve une copie de ce paquet, et demande à la destination un accusé de réception (dit "ACK"). Si Raydium ne recoit pas un ACK dans un délais donné, il renvoie le paquet une nouvelle fois, et ce jusqu'a recevoir l'ACK en question.
Je suis pour l'instant en train de bucher sur des problèmes intermédiaires de cette nouvelle couche (réception d'ACK en "double", par exemple), et il restera ensuite deux point cruciaux à gérer:
- Comment gérer les "attente avant ré-émission" ? (en fonction du temps ? après la réception d'un autre paquet de la part de la destination ? ...)
- Comment éviter les doublons (A envoie à B un paquet, B traine un peu pour envoyer son ACK mais le fait quand même, A à ré-envoyé entre temps son paquet (dépassement de l'attente avant ré-émission), et donc B recoit une seconde copie du paquet).

J'ai qq idées pour le second problème (doublons), mais le premier (attente) m'intringue beaucoup.. QQ1 sait comment fonctionne TCP sur ce point, par exemple ?

Bon, après pas mal de consultations de docs, ce problème de gestion de délais est plus ou moins réglé. Pour info, je me suis basé sur un algo utilisé par certaines implémentations TCP: l'algo Karn/Partridge, qui consiste en gros à prendre pour base le temps de retour du dernier ACK avec une moyenne pondérée, et poser le timeout (avant ré-émission, donc) à 2 fois cette valeur. Une ré-émission entraine d'office un doublement du temps de retour estimé. J'ai fixé une valeur plafond pour le temps de retour max à 2 secondes (soit 4 secondes pour le timeout).
J'ai ajouté un certain nombre de variables au coeur de network.c destinées aux statistiques réseaux: temps de retour, paquets perdus, écrasés (débordement de la pile d'attente), erreurs tx et rx, etc. qui serviront à affiner les différents réglages.

Pour les quelques tests que j'ai eu l'occasion de faire pour l'instant, ca semble pas mal du tout, sauf au moment de la connexion d'un nouveau client, ou il y'a un véritable rush entre le client et le serveur (rien de grave à priori). Reste à voir au travers d'un ligne type ADSL (et non avec un hub 100mbps ).

Kartagony va utiliser tout ca, et sera donc la plateforme idéale pour tester la fiabilité de la couche réseau de Raydium.

Pour mieux "surveiller" la nouvelle couche réseau de Raydium, j'ai ajouté un moniteur graphique, qui montre les taux d'émission et de réception, les paquets perdus, en doublon, les ack foireux, ...
Le but est d'essayer de comprendre pourquoi le réseau "s'enraye" dans certaines situations.

A l'écran, voilà le résultat (il manque encore la légende): http://raydium.cqfd-corp.org/captures/?image=110.jpg

va falloir garder les yeux ouverts

Héhé La graph ne défile pas vite, je te rassure
Sinon, grace à ce graph et aux "traces" (debug) de la couche réseau, j'ai trouvé une première source de problèmes pour la couche réseau: Le traitement des TCP-ID (identifiants uniques d'un paquet "important") semble avoir un comportement étrange lorsqu'une autre machine connectée possède et génère des TCP-ID dans la même plage de valeur. Je vais pousser plus les recherches sur ce point dès ce soir.

he bah au moins ça l'air de porter ces fruits

Bien, je pense que je viens juste de corriger les principales sources de problèmes de la couche réseau de Raydium... j'aurrai jamais imaginé que ce soit si compliqué !
Reste encore certaines choses à comprendre et à corriger (pourquoi y'a-t'il tant de paquets RAYDIUM_NETWORK_PACKET_ODE_NEWELEM comparé au nombre réel de création d'elements), et surtout: pourquoi ça marche pas au travers du net !

J'aurrai besoin d'un ou plusieurs volontaires pour tenter de comprendre et corriger ce dernier problème, d'ici qq temps.

préviens quand tu as besoin et je ferais en sorte d'être dispo.

J'ai ajouté au module "ODE Net" (le truc qui propage les objets ODE sur le réseau) une fonction de projection de trajectoires. Le résultat est très comparable à ce qui se passe lorsque l'on joue à Trackmania en réseau: les déplacements des autres objets réseaux sont fluides (ce qui n'était pas le cas avant avec Raydium), mais les objets sont "replacés" régulièrement à leur véritable place, ce qui donne une impression de tremblement. Cette nouvelle fonction permet de descendre le nombre de paquets envoyés par seconde de 30 à 20 (soit 10 Ko/sec en upload), et ca c'est bien

On a testé avec RyLe une connexion au travers d'Internet (chose qui ne marchait pas avant avec ODE Net), et après quelques réglages... ca marche !

La topologie était la suivante:
xfennec <-- LAN 100 Mbps --> serveur
ryle <-- ADSL 512/128 --> serveur

Le lien ADSL était assez fortement encombré dans les 2 sens (moins de 50% de dispo à vue de nez), et voilà les stats du coté du client "xfennec":

Raydium: Rx: 9906176 byte(s) / Tx: 7008768 bytes(s) / 27.22 min
Raydium: Transfert rates: Rx: 5.92 KB/s / Tx: 4.19 KB/s
Raydium: Packets (err): Tx: 930 re-emitted, Rx: 0 doubles
Raydium: Packets (err): Tx: 109 erased or lost, bogus ACK: 472

Je n'ai pas eu moyen de récupérer les stats du serveur et du client "RyLe", ce qui rend l'interprétation des résultats du client LAN un peu dure, mais au niveau du feeling, mis à part pendant les 30 premières secondes de jeu, c'était jouable !

Les deux client tournaient avec un "--ode-rate 5", c'est à dire que les positions des objets de la scène étaient rafraichis au maximum 5 fois par seconde... et ca ne se voyait pas tellement, preuve que la prédiction/projection de trajectoires fonctionne déjà pas mal
Je vais essayer d'organiser un gros test (avec au moins 3 personnes) bientot, si je trouve le temps de développer un nouveau test (à la trackmania, justement ), ou avec kartagony sinon.

A suivre !

on peut même ajouter

RyLe <--->wifi 802.11g<--->adsl 512/128<---> serveur histoire de, même si ça change ptet pas gd chose

_________________
Pentium IV 3c / 1Go / Gf-FX / WinXpSP2
AMD64_3000+ / 1Go / Gf 2mx /Mandriva amd64

un test multijoueurs a été fait à 4 joueurs avec Kartagony en réseau local, et l'on a constaté que l'on touche les limites assez vite. Je vais attendre de corriger tt les bugs connus de la couche réseau avant d'en tirer des conclusions

A ce propos, voilà ma TODO:
- Réduire le bruit engendré par les paquets NID-WHO à la connexion
- Meilleur protection contre les paquets en double (hors ACK eux même)
- Du coté serveur: délais de timeout par client, et non unique

Petite modif du code de prédiction de trajectoires, qui fait que les éléments d'un même objet distant ne se séparent plus comme c'était le cas avant (roues de la voitures qui sautaient partout, par exemple), ca rend le rendu des autres joueurs vraimment plus propre, à priori. Par contre, les network_Events (structures envoyées pour mettre à jour un élément sur le réseau) sont un peu plus gros (+12 octets par élément) ce qui réduit à 10 le nombre d'élément pouvant tenir dans un même paquet (de 512 octets). C'est un petit pas vers une couche réseau plus propre