Un clic propose. Mon serveur décide.

Partir de la connexion, puis examiner la demande.

À la réception, je renseigne la source à partir de l’appel côté serveur. Je contrôle ensuite le type d’opération autorisé, l’identifiant de transaction et les champs numériques attendus. Les règles de quantité dépendent du type d’action ; les opérations monétaires ont notamment leur propre règle de précision.

Je conserve aussi un historique temporaire des identifiants reçus. Si un identifiant est encore présent, je refuse la répétition. L’historique possède une durée configurée de cinq minutes et un nettoyage périodique. C’est une protection contre les répétitions dans cette fenêtre, pas une garantie d’exécution exactement une fois après un redémarrage.

Retrouver l’objet dans mon propre cache.

Pour un déplacement classique, je construis la liste des inventaires accessibles à partir de l’inventaire du personnage et des inventaires ouverts que mon serveur suit. Je confronte les identifiants de la demande à cette liste.

Je vérifie ensuite les emplacements : ils doivent être valides et respecter la capacité de chaque inventaire. Enfin, je retrouve l’objet dans le slot source de mon cache et je compare son identifiant à celui de la demande. Déclarer un identifiant d’objet ne suffit donc pas à faire apparaître cet objet à cet emplacement.

La démonstration suit ce chemin de déplacement. D’autres opérations, comme le don à un personnage, le ramassage ou certaines actions d’administration, passent par des traitements spécifiques. Leurs permissions et leurs conditions métier doivent être évaluées dans ces chemins.

Une demande peut vieillir dans la file.

Une demande valide à sa réception peut attendre pendant qu’une autre action modifie l’inventaire. J’ai donc ajouté une seconde vérification des versions attendues au démarrage du traitement, après la prise des verrous par l’ordonnanceur.

Quand la demande fournit des versions, je les compare à l’état courant à la réception, puis à nouveau avant d’exécuter l’action. En cas de décalage, je refuse et je force l’envoi d’un snapshot de l’inventaire concerné par la réponse pour remettre le client à jour.

Dans ce chemin, les versions attendues restent optionnelles : si elles ne sont pas fournies, ce contrôle ne s’applique pas. Je les présente comme une couche de détection des intentions périmées, avec les vérifications d’accès et les règles métier.

PSEUDO-CODE EXPLICATIFréception : identité, enveloppe, accès, objet, versions fournies
attente dans la file
acquisition des verrous
revérification des versions fournies
exécution de la règle métier ou refus explicite

Rendre le refus exploitable.

J’associe la réponse à l’identifiant de transaction. Elle indique le succès ou le refus, un motif et, lorsqu’un inventaire est disponible, sa version. Le client peut ainsi relier la réponse à l’action qui l’a déclenchée.

Je distingue également les motifs dans les observations du serveur : répétition, inventaire non accessible, objet incohérent ou version dépassée. Un refus reste un signal à interpréter dans son contexte ; une version périmée peut simplement résulter de deux actions concurrentes.