Opérations en Hors ligne

[atra27]

Stockage en RAM mais penseau dump et récupération depuis un fichier...sa serai bete qu'un plantage ou redémarrage efface les actions a faire...

[Sephi-Chan]

Redis sait répliquer les données sur le disque de manière asynchrone.

[Tyc]

Merci pour cette réponse

Je ne connaissais pas Redis.

D'après ce que j'ai vu, Node.js n'est pas bloquant. Pendant qu'une fonction s’exécute, on peut en lancer d'autres.

Pourquoi ne pas effectuer l'ordre d'actions suivant à chaque fois qu'on en a besoin ? :

Requête du serveur vers Node > Appel de la fonction construireBatiment() > le timer interne s'éxécute > Demande au serveur de mettre à jour la base.

En passant par redis, je ne vois pas dans quel ordre les actions serait effectuées :$

Sur ce, je vais aller tester ca et peut être aurais-je des réponses qui viendront d'elles mêmes

[Sephi-Chan]

Oui mais comment tu prends en charge la file d'attente ? Tu mets ton élément en file en spécifiant sa durée. Comment tu sais que le bâtiment peut commencer à être produit sur le champ ? Peut-être qu'il y a déjà un élément en production dans cette queue et qu'il y a déjà des éléments dans la file : il faut te mettre derrière celle-là.

Voilà ce que j'ai avec Redis (je rappelle que c'est un système de stockage qui associe une valeur à une clé) :

• une entrée de type hash pour la queue en elle même. Sa clé est de la forme queues:queue_id (à terme, la clé sera scopée avec l'identifiant du site qui utilise le service) et le hash dispose d'une clé pour le status (et une autre clé que je n'utilise pas, finalement. Je pourrais donc remplacer ce hash par une simple string contenant le statut) ;
  
• Ensuite, chaque élément de la file est également représenté par une entrée de type hash par élément : cette entrée à pour clé items:element_uuid et sa valeur est un hash avec des des clés pour la durée de construction et le status de la construction (là aussi, je pense simplifier).
  
• En plus de ça, je dispose d'une entrée de type list nommée queues:queue_id:items qui est simplement un tableau (donc ordonné) contenant les UUID des éléments apparetenant à la file.
  

Du coup, mettre des éléments dans la file est trivial : je crée un item, j'ajoute son identifiant à ma liste. Quand un élément s'achève, je supprime le premier élément de la liste (qui correspond à l'UUID de l'élément qui vient de s'achever), je prends le nouveau premier élément (qui correspond à l'UUID du prochain élément à lancer), je le lance et hop, le système est autonome.

J'ai donc pas mal de levier pour simplifier encore le système, maintenant que j'ai en tête les prochaines exigences.

[Tyc]

Je viens de comprendre la logique Du moins je crois ...

J’envisageais la chose avec la possibilité pour l'utilisateur de ne créer qu'une chose à la fois Quand il lance un bâtiment, il ne peut pas lancer quoique ce soit d'autre tant que le premier n'est pas fini.

Alors que toi dans ton exemple, les objets sont créés un par un mais peuvent être prévus à l'avance. Plus intéressant mais plus complexe également.

Penses-tu que dans ma vision des choses redis soit toujours nécessaire ? Un simple booléen suffirait à déterminer si l'utilisateur est en phase de construction ou non.

[Sephi-Chan]

L'intérêt de mon système est effectivement d'avoir plusieurs files qui tournent en parallèle. Si je code un jeu de type Stacraft, j'utiliserais une queue par bâtiment (ou deux si le joueur améliore son bâtiment pour créer des unités en parallèle).

Après, tu n'es pas obligé d'utiliser un système de stockage tiers : tu peux définir une variable globale qui sera initialisée au démarrage du serveur et que tu pourras utiliser dans tes requêtes.

[jean-baptiste]

Bonjour,
Je reviens sur ce sujet. J'ai l'impression (avis personnel) que l'on par sur une usine à gaz pour rien.
Si j'ai bien compris le but de cette mise en queue est de faire en sorte que lorsque l'utilisateur envoyé une action de construction celle ci est mise en queue puis si le personne ce déconnecte la queue est toujours active et sera traité ( terminé ) en temps réel quand le temps aura expiré.
Cela peu donc créer une file si il y a beaucoup de personne ?

Je vous propose une solution, qui pour mois, me parait un poile plus simple. Le but étant de ne pas alourdir les taches de traitement lors que l'utilisateur est déconnecté depuis longtemps. Pourquoi ne pas exécuter un cron tout les 4,3,2 voir 1h. Avantage un cron peu exécuter du php donc compatible sur n'importe quelle machine.( Il existe de plus des web service qui propose de cron pour les personnes qui n'ont pas de dédié).
Dans ce script je verrai, que celui effectué donc les calculs de retard pris. mise à jour du niveau des bâtiments terminé, et calcul des ressources. Cela limite donc le retard pris mais aussi la quantité de calcul à effectué si très régulier.

La simplicité n'ai telle pas mieux des fois ? A débattre.

J-B

[atra27]

Le but ici est d'effectuer l'action lorsque celle ci est effectivement terminée. On est donc dans un comportement synchrone entre le moment ou l'action se termine et le moment ou le jeu (bdd) subit la modification correspondante.

Le but n'est pas de limiter le retard comme tu le propose, mais de rendre ce retard quasi-nul.

Le probléme avec ton cron c'est que l'user doit attendre la prochaine mise a jour alors que son batiment devrai étre terminé... De plus, il n'y aura pas 1 appel spécifique par construction, mais plutot un appel a un script qui va ensuite effectuer toutes les taches (->on retrouve l'aspect usine a gaz dans ce script)

Dernier probléme: les appels son indépendants des actions a effectuer, ce qui est illogique vu qu'on se retrouvera avec des résolutions "a vide" (sans rien a résoudre) mais aussi des résolutions avec une quantité énorme d'action a résoudre (genre 10000 constructions sur l'ensemble du jeu, etc etc)

Ta méthode fonctionnerais... mais elle ne répond pas a la problématique: effectuer l'action en un pseudo real-time!

[jean-baptiste]

Oui mais justement c'est ce coté real-time que je remet en cause. Le propre du jeux par navigateur est justement ce coté non réel time. La web est d’ailleurs que très peu réel time ( il y des exceptions). Les gens de toute façon le pense comme ça.
Pour ce qui est de ma proposition quand l'utilisateur est connecté c'est lui qui effectue les actions de mise à jour. De même pour actions extérieure ( exemple: attaque).
Je trouve ça justement moi la mise en place d'une queue assez "usine à gaz" du faite de la lourdeur de la mise en place par rapport au gain finale pour l'utilisateur. A part le coté satisfaction du développeur du coté real time, l'utilisateur ne verra pas lui que c'est réel time derrière.

Après c'est sur que c'est assez intéressent cette approche (voir très). Mais je vois pas l’intérêt pour les jeux par navigateur ( sauf si le jeux est conçu sur un modèle synchrone du début jusqu'à la fin)

J-B

[Sephi-Chan]

@ Jean-Baptise.

Le système permet de créer des files indépendantes (autant qu'on veut) qui tournent en parallèle et de notifier en temps réel la fin d'une construction.

Ton système de cron doit être codé dans ton jeu, les tâches qui s'occupe de la résolution de la queue également. Il n'est pas plus simple car le cron effectue bêtement les tâches, qu'il y ai des résolutions à faire ou non. Ce n'est pas plus léger, ni plus performant.

Et c'est encore pire pour la résolution des actions "au besoin". C'est la technique pauvre : celle qui fait une opération longue au chargement d'une page, ce qui rend la requête longue HTTP et qui fait attendre l'utilisateur. C'est facile mais mauvais à tout point de vue : peu performant et l'expérience utilisateur est nulle vu que ton joueur attend qu'une page se charge (et même 1 ou 2 secondes ça se sent).

Avec l'emploi d'un server indépendant et qui gère très bien le temps, tu dilues ça dans le temps et tu profites de l'asynchrone : c'est bien plus performant et agréable pour l'utilisateur. Ta machine ET tes joueurs te remercieront.

Alors que le serveur que je propose lance simplement un timer, comme tout développeur sait le faire en Javascript. C'est trivial et performant.

Ensuite, le développeur du jeu implémente une page de callback (qui sera appelée par le serveur de queue quand une action sera terminée, pour permettre au site de faire ce qu'il veut (mises à jours de la base de données, push au joueurs). La complexité que tu dénonces, c'est juste l'installation de Node…

De plus, je propose 2 formules à ma solution :

• S'il a un serveur dédié/VPS, il peut prendre le code de mon PQS (Production Queue Server) et le lancer très simplement sur son serveur. Son jeu reste très simple : il envoie des requêtes HTTP quand il lance une construction et il en reçoit une quand une construction s'achève. Toute la partie timing est effectué du côté PQS en profitant des performances de NodeJS sur cette partie.
  
• S'il n'a pas de serveur dédié, il peut utiliser le PQS (Production Queue Service) sans rien avoir à installer, il devient par contre dépendant de mon service. Là aussi, son code reste très simple, pas d'extra (à part l'envoie et la reception de la requête HTTP) ;
  

Le temps réel apporte beaucoup dans un jeu, autant en terme de possibilité de gameplay que d'expérience utilisateur. C'est trop bête de se murer dans le Web d'il y a 10 ans. Autant exploiter les possibilités de maintenant.