[KTZ-Dev] KaTZ-Link V2

[KaTZe]

Je créé ce topic pour garder trace des échanges avec Etcher et Demon, relatifs au développement de la V2 du KaTZ-Link.

Objectifs du Link-V2 : (par priorité)

1> Garder une stabilité aussi bonne que celle de la V1 (plusieures heures de mission sans déco)
2> Optimiser (si possible) la transmission d'information SIOC<>Pit
3> Permettre le multi connection (plusieurs pit sur un avion) (écolage+pilotage)
4> Mieux intégrer les commandes TS
5> Possibilité d'échange de documents, d'information en cours de vol.

Problèmes Connus avec la V1 :

1> Pause du Link (en écoute) en l'absence d'informations descendantes de SIOC (donc quand DCS est en pause)
2> Détection de la déconnexion du pit (ping-pong sur websocket), lent et imparfait (en particulier dans le cas 1)
3> Qui dit Link en pause , dit commande TS inactive (multithread séquentiel et non parallèle).


Status à compléter durant le développement

[Postal2]

Ont peut pas mettre j'aime !

[KaTZe]

Discussion KaTZe-Etcher du 2015/02/11 dans la nuit

J'ai dis une connerie, ce soir.

Si SIOC n'est pas connecté à DCS, le système de ping-pong ne fonctionne pas.
Donc, la boucle du Link reste bloquée en attente d'une instruction de SIOC, et donc elle ne peut pas écouter puis envoyer les commandes TS.

Bref, il faudrait que je modifie le Link, pour qu'il continue de tourner même sans input de SIOC (socket non bloquante). Malheureusement c'est sur ma todo liste.

Idem pour le Link, sans info. du Pit (retour du pong), il considère que le pit est déco, et il libère la socket. Donc pour le KaTZ-Radio, tout seul, j'avais fait un link simplifié, sans système de pingpong.

Bref faut que j'y réfléchisse

Si tu veux je m'en occupe ?

Merci,

Je propose dans un premier temps de calmer un peu le jeu, et de vérifier que çà tourne stable (EKPI + le KatzPit comme actuel).

Pour le Link, il faudra effectivement travailler sur la version multi, et en effet j’atteins ma limite de compétence avec "l’orienté objet" , c'est pour çà que je m’étais arrêté au mono-poste.
Of course ton aide, ou même ton développement sera indispensable.

Il faudrait qu'on discute plus généralement de l'architecture du Link-V2
J'ai pas mal galéré avec les socket bloquantes, vs non bloquantes, et la mise en place du ping-pong pour détecter une déconnexion et libérer la socket.

--------------------

Coté WebSocket, lorsqu'on arrive dans la boucle d'envoi/écoute, je teste si la socket est ready (5ms):

CODE

ready_to_read, ready_to_write, in_error = select.select(miaou_in, miaou_out, miaou_in, 0.05)

Si elle a reçu un message du KaTZ-Pit, je le lis, sinon j'incrémente un compteur.
Si le compteur dépasse n boucles sans recevoir de nouvelle du pit (le seuil (pulse_ws), alors il considère qu'il est déco, ferme la socket et se remet en écoute).

Pour s'assurer de ce trafic montant, le Link envoi à SIOC un pulseur (l'heure de mission), sur le canal 9 , à chaque boucle. (Accessoirement ce pulseur indique à SIOC qu'on est en écoute prêt à recevoir des ordres (Sans lui SIOC nous déco).

Sioc avec un intervalle de 5 secondes, le copie sur le canal 8, et le revoie ainsi au Link , qui le transmet au Pit (sous la forme "8=heure"), dans le pit la réception de ce ping, déclenche une réponse pong sur le Canal 7

C'est dans la fonction serverws_message

CODE

    if (KaTZPit_data["Ping"] != KaTZPit_data["Ping_old"]){
        CmdSiocSpe(7, KaTZPit_data["Ping"])
        KaTZPit_data["Ping_old"] = KaTZPit_data["Ping"]

Donc toutes les 5 secondes (soit 50 boucles de 0.1 secondes maximum), même si on n'effectue pas de commande DCS depuis le pit, Link recoit un message du Pit sous forme du pong. Le compteur de "boucles sans réponse" est ainsi réinitialisé.

--------------------

Bref ce système de ping/pong réfléchi sur SIOC, fonctionne très bien et le système est super stable pendant des vols de plusieurs heures (c'est pour cela, que je suis super prudent avec les évolutions du Link).

--------------------

Là ou j'ai un problème, çà n'est donc pas côté WebSocket, mais du côté "client SIOC, client TS"
Pour TS pas de problème, comme on ne fait qu'envoyer des ordres (out only), on flood en UDP sur TS. (D'ailleurs si on met au point un retour de canal TS, il faudra alors changer pour un système in/out ??)

Pour SIOC , on est en TCP

A) Les envois sont effectué par

CODE

try:
    sioc_socket.sendall(msg_cmd.encode())
except:

Si çà plante on considère qu'on a perdu la connexion avec SIOC (ou qu'il n'est pas démarré, et le programme stoppe et part dans la boucle de connexion avec message à l'utilisateur, et tentative de reco toutes les 15 secondes.

Les réceptions sont effectuées par

CODE

# Message recu de SIOC
     try:
        KTZmain.msgSioc = sioc_socket.recv(4096).decode()
      except:

Or, cette instruction est bloquante, tant qu'on a pas de réponse de SIOC, la boucle (et donc tout le Link est en pause là).
C'est ce qui explique que si l'on démarre SIOC, sans DCS, puis le Link et le Pit, la commande TS ne fonctionne pas. Le link est en pause, en attente de recevoir une info. de SIOC.

C'est pour çà que j'exporte toujours chaque seconde l'heure de mission depuis DCS, pour assurer un flux de données descendantes, et garder le Link actif. Ainsi dès la "dépause", le Link, et donc le contrôle de TS fonctionne.

La solution au problème, (que j'avais utilisé dans la KaTZ-Radio), était de ne plus écouter SIOC, et de désactiver le PingPong, et le Link tourne en boucle ... mais çà n'est pas applicable pour le Pit.

Pour la V2, il faudrait trouver une instruction NON BLOCANTE de client TCP, qui écoute la socket, et sans réponse passe à la suite.
A ce moment, le TS commande fonctionnera, même sans connexion SIOC.

Autre alternative, que j'utilise lorsque je travaille sur les pits, j'ai un générateurs de pulsation en python (que j'appelle "DCS-Shadows"), qui se connecte sur SIOC et créé un traffic descendant virtuel (comme si DCS était présent). Ce générateur pourrait être intégré au Link dans un thread spécifique, avec comme but de rebondir sur SIOC en évitant ainsi le blocage de la socket d'écoute.

A discuter ce pm si tu es là

Ce message a été modifié par KaTZe - 12 Feb 2015, 11:34.

[etcher]

Je suis en train de me documenter sur l'implémentation Qt des sockets abstraits. L'idéal serait d'utiliser des sockets TCP KEEP_ALIVE, de manière à les blinder complètement contre la déco.

La thread principale serait à l'écoute de demandes de connexion, et créerait des threads secondaires chargées de la transmission de messages. On fait ainsi sauter la limite de connexion d'une personne par pit. J'utiliserai des threads bloquantes en lecture de manière à économiser au maximum les ressources, avec 100ms entre les checks pour les join. L'écriture sera épisodique et sera déclenchée par signal, donc ne pèsera rien non plus. On a donc les avantages des deux mondes.

Il y aura un socket en écoute, un second dédié à la connexion avec SIOC (TCP KEEP_ALIVE), éventuellement un troisième pour TS, et des sous-socket spawnés par le premier pour gérer les connexions Pit entrantes. Ils ne se bloqueront jamais les uns les autres, et on peut faire transiter les chaînes de données via deux queues principales par élément (SIOC, TS, Pit). Le socket principal sera bloquant, étant donné qu'il n' a rien d'autre à faire que d'attendre les demandes de connexion et d'effectuer l'opération de transfert vers le sous-socket.

Tout ce petit monde vit chacun dans sa thread, et dès qu'il y a une déco ou un plantage on peut aller aux nouvelles via le socket principal pour demander s'il faut faire perdurer la connexion ou si la déco était volontaire. Dans le pire des cas on aura 50ms de désynchro.

J'ai déjà une bonne idée de la structure à donner au programme, la seule chose à changer de toute façon ce serait la couche réseau. J'espère juste que ce sera possible de faire passer la connexion TS en TCP, parce que le flood UDP c'est pas vraiment l'idéal niveau fiabilité.

Je laisse un peu EKPI vivre sa vie pour le moment, j'ai besoin des retours utilisateur sur les bugs actuels avant d'en ajouter de nouveaux, donc je vais commencer à travailler sur un draft d'une nouvelle version du link pour ce week-end, qu'on puisse décider ensembles d'une direction à prendre.

[etcher]

Tant qu'on y est on essaierait pas d'implémenter toute les fonctions du SIOC dans le Link ? Ce serait une étape en moins à l'installation.

[KaTZe]

Deux commentaires :

J'ai découvert les websockets grâce à Le Créole, et honnêtement en terme de fiabilité et sécurité c'est remarquable ... je ne pense pas qu'on ai intérêt à changer la relation Link-Pit qui fonctionne bien.

Quand au TCP en java bof bof ...; , à ce moment on aurait pu mettre le pit direct sur SIOC

Si l'on veut se passer de SIOC, il faut alors faire appel à la solution de LeCréole, qui consiste à directement créer la websocket dans l'export de DCS (plus de SIOC, plus de Link), mais on perd la commande TS, la compatibilité avec les pit en dur, ainsi que le debugging/developpement facile grace à la console IOCP.

Par ailleurs entre une gestion par SIOC qui est compilé et super stable, et cette merde de Lua, je n'hésite pas une seconde.

Perso, j'aime bien SIOC, je le démarre avec le PC, et je n'y pense plus, çà bouffe rien et c'est quasi instantané
Idéalement il aurait fallu un SIOC/WebSocket compilé, stable, direct sur DCS, et autant de clients que désirés

[etcher]

Ok donc on garde SIOC.

Qu'est-ce qu'il a le TCP en Javascript ? Il est juste lourd à mort comme tout le reste de Java ou il est complètement pourri ?

[etcher]

Idéalement il aurait fallu un SIOC/WebSocket compilé, stable, direct sur DCS, et autant de clients que désirés

Plussoiement

[KaTZe]

Bon, ben le père Noël (Etcher) est passé cette nuit vers 3hr du matin

On test et on vous tient au jus, mais sur le papier, c'est une tuerie "teaser inside"

[KaTZe]

Petit test rapide du KaTZ-Link V2 (qui devrait s'appeler Etch-Link V2 maintenant), c'est juste impressionnant.
Etcher a réussit à diviser le timing du programme par un facteur 10 (de 200ms à une 20aine de ms).

Du coup le KaTZ-Pit fonctionne en quasi instantané, avec rotation immédiate et fluide des cadrans

En prime :

> traitement multipit, je viens de faire un vol avec 4 pit connectés
Ce qui vous donne la possibilité de mettre les cadrans sur un écran html, et les menus sur un autre, et à plusieurs personnes de suivre votre vol "live".

> gestion du DCS focus pour rendre à DCS le focus quand vous avez clické sur le pit
le timing du focus est réglable sur l'interface

La détection des connection/déconnection des pits est instantanée, et suivie par une interface graphique


On va donc s'attaquer aux tests de stabilité maintenant, et en multipit via internet

Miaouououou