[LOTATC] Au sujet des freezes

[Ezor]

Sauf que la bande passante utilisée est pas exactement la même. Avec 40 clients qui pompent toute la bande passante c'est pas dit que l'export lua se sente à l'aise

Dailleurs comment vous avez identifié où se situait le goulot avec lotatc ? (piti test ?)

On a testé pendant plus d'une heure en étudiant les trames entre les différentes parties.

Comme je l'ai déjà dis nous avons conclu que le problème vient du transfert de données entre le LOTATC Server et le LOTATC client.

LOTATC Server reçoit correctement toutes les informations, traite ces données et les réémet à tout les clients et c'est là que le bas blaisse. Les trames sortent de LOTATC Server mais disparaissent dans la nature une fois sur deux (voir systématiquement).

Le problème est plus d'ordre réseau donc, d'autant que nous avons pu reproduire le problème du LAN avec 100 clients IA (sans même un seul client humain).

On soupsonne la taille maximale des trames définis dans LOTATC être la source du problème. Ca passe correctement sur un réseau dit "lan" comme le VPN, ça passe pas du tout voir quasiement pas par le réseau internet classique et ça clignote en lan (ça on ne l'explique pas non plus).

[MajorBug]

C'était même plus subtil que ça : c'était fluide pour certains et invivable pour d'autres ...

En tout cas bien vu pour les tests

[Lynx]

Je plussoie fortement, ce sera certainement un point qui soulagera la vie de tout le monde... Pilotes comme contrôleurs... Sur le net ou en LAN, à tester le plus vite possible.
Merci à vous deux.

[HubMan]

On a testé pendant plus d'une heure en étudiant les trames entre les différentes parties.

Comme je l'ai déjà dis nous avons conclu que le problème vient du transfert de données entre le LOTATC Server et le LOTATC client.

LOTATC Server reçoit correctement toutes les informations, traite ces données et les réémet à tout les clients et c'est là que le bas blaisse. Les trames sortent de LOTATC Server mais disparaissent dans la nature une fois sur deux (voir systématiquement).

Le problème est plus d'ordre réseau donc, d'autant que nous avons pu reproduire le problème du LAN avec 100 clients IA (sans même un seul client humain).

On soupsonne la taille maximale des trames définis dans LOTATC être la source du problème. Ca passe correctement sur un réseau dit "lan" comme le VPN, ça passe pas du tout voir quasiement pas par le réseau internet classique et ça clignote en lan (ça on ne l'explique pas non plus).

Salut Ezor, salut Doug petit déterrage de post : il y a de très fortes chances que les freeze viennent de là aussi : si je me souviens bien la taille maximale possible d'un datagramme Ip, c'est 65535 octets ie pour un message udp 65507 octets (on enlève la taille du header IP).

Le hic, c'est que c'est pas parce que la norme permet d'envoyer des paquets de bourrins en une seule fois que ça se passera bien derrière. Un paquet de 65Ko, c'est beaucoup trop gros pour beaucoup d'équipements réseaux.

Les PC, les routeurs etc... possèdent donc une taille limite de message, au dela de laquelle, le message sera fragmenté / découpé en morceaux (en trames IP), ça s'appelle la MTU (Maximum Transmission Unit). Le soucis, se trouve alors au niveau du réassemblage des bouts : il n'y aucun méchanisme qui assure au niveau IP que des paquets perdus seront redemandés (par contre, le désenquencement est géré). En conséquence, il suffit qu'un seul des petits paquets fragmenté soit perdu pour que le paquet complet soit perdu.

Et vu qu'UDP ne gère pas la perte de packets, contrairement à TCP, et que sur le net, la probabilité de perte de paquets fragmentés est très supérieure à celle d'un LAN, forcèment, ça coince et c'est lié à la façon d'écrire son code réseau : si la taille des messages est proportionnelle à la quantité d'info à véhiculer, il y a forcèment un moment où ça explose, indépendamment de la bande passante disponible

La RFC 791 précise d'ailleurs bien qu'au dessus de 576 octets pour un datagramme IP, ça risque très fortement d'être le bazar et qu'il vaut mieux l'éviter.
En tenant compte des tailles de header etc... On peut dire que 512 octets de données pour un message UDP, c'est le maximum conseillé.

Vu que les sources sont paumées et que de toutes façon, LOTAC 2.0 est dans le pipe, ça n'a pas de sens de s'acharner là dessus, je dis surtout ça en pensant à vos devs actuels , je ne sais pas comment vous allez vous y prendre à ce niveau là, mais il vaudrait surement mieux considérer que la compression ne réglerera pas forcèment ces problèmes et que si vous utilisez le protocole UDP qui est quand même beaucoup plus adapté à du flux que TCP, il vaudrait mieux véhiculer l'information d'entrée de jeu sous forme de petits messages de 512octets, parce que sinon, un jour ou l'autre, ça sautera pour un routeur plus restricitf que d'habitude qui n'aimera pas des paquets de 2ko


Ciao

Hub.

PS : 512 octets, c'est -très- petit, c'est plus ou moins 0.5ko : un paquet de 20ko a de très fortes chances de se faire fragmenter et mettre le soukh, alors que ça n'a pas l'air si gros sur les standards actuels
PPS : Le fait d'employer un VPN doit encapsuler le traffic UDP à travers un autre protocole et découper les gros messages UDP en petit messages VPN réassemblés proprement de l'autre coté...

Ce message a été modifié par HubMan - 10 Aug 2007, 11:06.

[Doug]

Oui, je pense utiliser UDP entre LockOn et le serveur LOTATC puis TCP entre les clients LOTATC et serveur LOTATC.