avec erlang il est possible d'arriver assez rapidement à un prototype.
quand l'application se lance, on crée un processus de type serveur qui écoute sur un port TCP ou des requêtes HTTP.
Quand on lui demande de créer une queue, il lance un nouveau processus de type queue qui va se mettre en attente d'éléments, et va stocker l'identifiant de ce processus dans un dictionnaire key/value qui associera une queue à son processus.
Il associe également à la queue (même dictionnaire ou un autre) des infos de la requête qui lui permettent de renvoyer les infos (priciplament élément terminé). les informations comme queue créée, élément ajouté sont renvoyées en réponse de la requête HTTP directement (possible en TCP ?). ces infos sont une adresse de callback, une commande à lancer, etc.
Quand on lui demande d'ajouter un élément à une queue, on lui envoie un identifiant d'élément, une durée, et la queue à laquelle ajouter cet élément.
Le serveur récupère l'identifiant de processus dans le dictionnaire grâce à l'identifiant de queue et lui envoie l'élément à ajouter et la durée.
Le processus queue entretient un état : occupé / disponible / ...
Quand on lui envoie un élément, il crée un identifiant interne et stocke le couple identifiant/élément à la fin de sa liste de tâches puis on lance une fonction de vérification.
fonction de verif: si l'état actuel est disponible ET si la file n'est pas vide, on passe en occupé, on chope le premier élément de la liste avec son identifiant et on envoie le tout à un timer. sinon on ne fait rien.
Quand un timer se termine, il renvoie au processus queue une info lui indiquant l'identifiant d'élément préalablement passée, et que l'élément concerné à fini sa production. Le processus queue relaie l'information au processus pricipal (qui stocke les couples queue/processus), supprime l'élément correspondant à l'identifiant de sa liste, passe en disponible et lance la fonction de vérification.
Le timer est un autre processus, donc il avance de namière concurrente avec les processus queue et le processus serveur global.
Le processus principal qui à reçu l'information de la réponse va utiliser les infos préalablement stockées (adresse de callback, une commande à lancer, etc.) pour notifier le propriétaire de la queue qu'un élément vient de se terminer.
Si on compte lancer 100 000 qeueues, et bien que des couple id/pid ne soient pas très lourds, vaut mieux faire un backup régulier de tout ça en base de données plutot que de tout garder en mémoire vive.
Idem pour les éléments en construction. Mais si toute la logique de la construction des éléments est gérée ailleurs que dans l'appli, elle ne fait vraiment qu'associer des identifiants à des processus et des timers à des identifiants, donc l'impact mémoire est très très petit.
On peut faire un backup en base de données régulièrement, par exemple sauvegarder la file d'une que à chaque fois qu'un élément se termine, et sauvegarder la liste des queues.
Ainsi, au démarrage de l'application, si la table des queues n'est pas vide, le serveur global relance immédiatement des queues avec leur nom enregistré, les queues une fois lancées vont voir dans la base si une file n'existe pas déjà. (Il faut pour cela communiquer aux queues leurs propres identifiants). Et si une file existe elle les rechargent.
Avec ça, même si le système entier crashe une fois par minutes, si les temps de production ne sont pas inférieurs à quelques secondes ça reste du 'soft real time'
____
Via le protocole HTTP, faire un client pour cette appli en PHP est une affaire de minutes. en ruby je ne sais pas mais je suppose que c'est aussi simple, sinon plus.
__________
J'écris tout ce flood pasque je réfléchis en même temps, j'ai prévu d'implémenter un truc du style pour mon propre jeu mais je ne sais pas s'il sera possible d'en faire un truc standalone.
quand l'application se lance, on crée un processus de type serveur qui écoute sur un port TCP ou des requêtes HTTP.
Quand on lui demande de créer une queue, il lance un nouveau processus de type queue qui va se mettre en attente d'éléments, et va stocker l'identifiant de ce processus dans un dictionnaire key/value qui associera une queue à son processus.
Il associe également à la queue (même dictionnaire ou un autre) des infos de la requête qui lui permettent de renvoyer les infos (priciplament élément terminé). les informations comme queue créée, élément ajouté sont renvoyées en réponse de la requête HTTP directement (possible en TCP ?). ces infos sont une adresse de callback, une commande à lancer, etc.
Quand on lui demande d'ajouter un élément à une queue, on lui envoie un identifiant d'élément, une durée, et la queue à laquelle ajouter cet élément.
Le serveur récupère l'identifiant de processus dans le dictionnaire grâce à l'identifiant de queue et lui envoie l'élément à ajouter et la durée.
Le processus queue entretient un état : occupé / disponible / ...
Quand on lui envoie un élément, il crée un identifiant interne et stocke le couple identifiant/élément à la fin de sa liste de tâches puis on lance une fonction de vérification.
fonction de verif: si l'état actuel est disponible ET si la file n'est pas vide, on passe en occupé, on chope le premier élément de la liste avec son identifiant et on envoie le tout à un timer. sinon on ne fait rien.
Quand un timer se termine, il renvoie au processus queue une info lui indiquant l'identifiant d'élément préalablement passée, et que l'élément concerné à fini sa production. Le processus queue relaie l'information au processus pricipal (qui stocke les couples queue/processus), supprime l'élément correspondant à l'identifiant de sa liste, passe en disponible et lance la fonction de vérification.
Le timer est un autre processus, donc il avance de namière concurrente avec les processus queue et le processus serveur global.
Le processus principal qui à reçu l'information de la réponse va utiliser les infos préalablement stockées (adresse de callback, une commande à lancer, etc.) pour notifier le propriétaire de la queue qu'un élément vient de se terminer.
Si on compte lancer 100 000 qeueues, et bien que des couple id/pid ne soient pas très lourds, vaut mieux faire un backup régulier de tout ça en base de données plutot que de tout garder en mémoire vive.
Idem pour les éléments en construction. Mais si toute la logique de la construction des éléments est gérée ailleurs que dans l'appli, elle ne fait vraiment qu'associer des identifiants à des processus et des timers à des identifiants, donc l'impact mémoire est très très petit.
On peut faire un backup en base de données régulièrement, par exemple sauvegarder la file d'une que à chaque fois qu'un élément se termine, et sauvegarder la liste des queues.
Ainsi, au démarrage de l'application, si la table des queues n'est pas vide, le serveur global relance immédiatement des queues avec leur nom enregistré, les queues une fois lancées vont voir dans la base si une file n'existe pas déjà. (Il faut pour cela communiquer aux queues leurs propres identifiants). Et si une file existe elle les rechargent.
Avec ça, même si le système entier crashe une fois par minutes, si les temps de production ne sont pas inférieurs à quelques secondes ça reste du 'soft real time'
____
Via le protocole HTTP, faire un client pour cette appli en PHP est une affaire de minutes. en ruby je ne sais pas mais je suppose que c'est aussi simple, sinon plus.
__________
J'écris tout ce flood pasque je réfléchis en même temps, j'ai prévu d'implémenter un truc du style pour mon propre jeu mais je ne sais pas s'il sera possible d'en faire un truc standalone.