Quelle architecture entre Cyborg-plateforme et les jeux/applis ?

Gouayave commented 7 years ago

Yo. Je suis en train de tester depuis quelques jours les différentes possibilités d'architecture de Cyborg.

Pour l'instant coté client, je pense qu'un iFrame (balise HTML qui permet d’emboîter des pages web, les unes dans les autres) est une bonne solution et évite le rafraîchissement complet de l'interface web lors d'une demande de contenue par l'utilisateur. Et donc la déconnexion de socket.io des utilisateurs. Malheureusement, pas possible de faire des requête sur d'autres port/adresses (à vérifier !).

Par contre coté serveur, plusieurs solutions peuvent être envisagés. Le but est de définir quel mécanisme va opéré lors de la création d'une instance de jeu et comment se fait la communication entre un jeu et Cyborg.

Sachant que:

Des utilisateurs doivent pouvoir créer des instances de plusieurs jeux en parallèles.
Il ne faut pas qu'un bug dans un jeu affecte Cyborg.
Etre attentif au performance.
C'est bien si on contraint pas un jeu à être développer en JavaScript.
Cyborg et le jeu doivent géré les événements utilisateurs et joueurs (Nouvelle connexion, déconnexion, exécution d'un mini-jeu, etc ?...) et s'informer mutuellement .
Si "pas possible de faire des requête sur d'autres port/adresses avec iFrame" Alors c'est Cyborg le proxy.

Donc, 3 points à définir:

Quel mécanisme pour la création d'une instance ?

Solution # A1: Une instance de jeu est un script JavaScript que Cyborg exécute comme un module (require de Noje.js).
Solution # A2: Chaque jeu est un processus lourd (new process via fork). Les processus légers n'existent pas en Node.js (à vérifier !).

Quel moyen de communication ?

Solution # B1: Chaque jeu à son propre serveur web et Cyborg gère la redirection des requêtes par proxy (ex: Cyborg écoute sur le port 80 et redirige sur le 3000, port du jeu, utilisation de http-proxy ).
Solution # B2:(Si A2) La communication se fait par IPC .
Solution # B3: (si A1) La communication se fait en manipulant des objets communs (ex watch d'une variable global) ou en utilisant les events de Node.js

Existe t'il d'autre possibilités ?

Si vous avez des idées, propositions, arguments, je suis preneur.

JeanMax commented 7 years ago

Dans le cas du require ( # A1), un try catch suffirait pour gerer les plugins qui crash nan ? Ca me parait le plus simple/performant. L'avantage du fork cest qu'on pourrait facilement executer des trucs fait dans un autre langage. La soluce B1 me semble toujours un peu overkill, mais ptet que jvois pas bien.

Gouayave commented 7 years ago

Dans le cas # A1 , j'ai peur qu'un script bloquant puisse empêcher le reste de fonctionner et qu'il faille attendre la fin de son exécution pour continuer. Je vais essayer de voir ça ...

JeanMax commented 7 years ago

Ah ouais ! Quoique js cest pas ce qu'on fait de plus bloquant... jfais des tests de memoire quand jai le rasp sous la main

Gouayave commented 7 years ago

Enfin si il est dans une boucle infinie c'est toute la plateforme qu'est en bad. Cool pour les tests :)

JeanMax / cyborg