En cherchant cette après-midi avec Ezor, nous avons constatés qu'il n'y avait plus de freeze sur le VPN dedidoug. Si vous voulez tester, connectez vous d'abord au VPN et sous LOTATC, entrez l'adresse du serveur LOTATC en 10.0.0.X. Le reste ne change pas.

Celà a-t-il une réèlle utilité pour les futures Lan's et missions sur Dédidoug ???
Notre vie de virtupilots va-t-elle en être changée???

Non pas pour les pilotes. Cela ne rentre en compte que pour le serveur LOTATC et les clients LOTATC. C'est entre eu deux que le VPN (tunnel sécurisé) permet de ne rien perdre en route.

Quelle version de LoTATC ?

Et je ne comprend pas comment un VPN peut faire mieux qu'en LAN. Vous étiez combien ?

Az'

Ben oui, bonne question, car au lan on s'est aperçu que les freezes disparaissaient lorsqu'il y avait moins de clients sur lock-on et moins d'IA en vol.

Plus de 60 avions en vol

Via l'adresse internet direct, on avait aucun rafraichissement des données ou aucun contact tout court (alors qu'il n'y a aucun problème sur une petite mission). Tandis que Via le VPN, on avait un rafraichissement parfait et pas de freeze pour l'intégralité des contacts.

Version 1.0 de LOTATC

Edit: et si je ne me trompe pas on était sur un nouveau lotatc.lua de Doug

Je doute que le VPN fasse mieux qu'en LAN. En revanche comme dit Ezor, il resoud le problème sur Internet. On ne sait toujours pas pourquoi mais ca marche mieux.

Correction Ezor, il y en avait plus de 100

En effet c'était sans le export.lua mais j'ai repris une bonne partie du code de Brothers. Je vais mettre ca dans le wiki.

100 avions et 100 clients c'est pas exactement la même chose, loin de là

100 avions c'est 100 avions qui circulent entre le serveur LOTATC et le/les client(s) LOTATC.

Que ce soit des clients ou des IA ne change donc rien.

Et comme le problème se situe entre LOTATC serveur et LOTATC client, le type de joueur n'a donc aucun impact.

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).

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

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.

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é...

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