Dans Minecraft, un téléphone programmable reste d’abord un objet du jeu. Je le pose, je l’allume, je regarde son écran. Pourtant, dès qu’il doit consulter un compte ou joindre une borne, ce petit bloc devient un client réseau.
C’est là que PIL OS a commencé à m’apprendre autre chose que du Lua. Le problème n’était plus seulement de faire communiquer des machines. Il fallait décider ce qui se passe quand l’une d’elles ne répond plus.
## Le monde continue sans la réponse
Mon réseau contient un serveur central, des téléphones, des bornes ATM et une console d’administration. Chaque machine a son propre programme et son propre écran. Elles fonctionnent dans CC:Tweaked, qui ajoute notamment des ordinateurs programmables à Minecraft.
Quand un téléphone envoie une demande au serveur, plusieurs résultats sont possibles :
- le serveur accepte et répond ;
- le serveur refuse avec une erreur ;
- aucune réponse n’arrive.
Le troisième cas est le plus facile à oublier. Dans une fonction locale, j’ai l’habitude d’obtenir une valeur ou une erreur. Sur un réseau, l’absence de résultat est elle-même un résultat.
La documentation de `rednet.send` le précise clairement : réussir l’envoi ne garantit pas que le message a été reçu. De son côté, `rednet.receive` accepte un délai maximal avant d’abandonner l’attente.
Dans PIL OS, mes requêtes ne peuvent donc pas attendre éternellement. Le client envoie son message, calcule une échéance, puis attend seulement le temps restant. Si rien n’arrive, il renvoie pas de reponse.
Ce n’est pas une gestion d’erreur ajoutée après coup. C’est une sortie normale de l’échange.
## Le client-serveur devient visible
Sur un schéma, une architecture client-serveur tient dans deux rectangles et une flèche. Dans Minecraft, elle occupe de vrais blocs séparés.
Le téléphone peut afficher son interface pendant que le serveur tourne ailleurs. La borne ATM peut démarrer sans réussir à le trouver. La console d’administration peut demander la liste des téléphones et ne rien recevoir. Le jeu rend la séparation physique, donc difficile à ignorer.
Cette contrainte m’a obligé à ne pas confondre trois choses :
- avoir un modem ;
- réussir à envoyer un message ;
- obtenir une réponse exploitable.
Le modem donne un moyen de transport. Il ne transforme pas plusieurs programmes indépendants en une seule application fiable.
Dans le code du réseau, je localise d’abord le serveur. S’il est absent, la demande échoue immédiatement avec serveur introuvable. S’il était connu mais ne répond pas avant l’échéance, le résultat devient pas de reponse. Enfin, une réponse n’est acceptée que si elle vient du serveur attendu et correspond à l’action demandée.
Cette dernière vérification compte aussi. Recevoir un message ne signifie pas avoir reçu la réponse.
## Attendre est un état de l’interface
Le réseau a aussi changé ma manière de regarder les écrans du jeu.
Une borne qui affiche un solde donne l’impression que cette valeur est disponible immédiatement. En réalité, l’écran dépend d’une demande envoyée à une autre machine. Entre le clic et l’affichage, il existe un état d’attente. Puis éventuellement un refus ou un serveur injoignable.
Je ne peux pas supprimer ces états avec une meilleure interface. Je peux seulement les représenter au lieu de laisser la machine bloquée.
C’est probablement le point le plus utile que je garde de ce réseau Minecraft : une dépendance distante doit toujours avoir une limite. Pas uniquement une limite en secondes, mais une limite dans ce que le reste du logiciel accepte de lui sacrifier.
Aujourd’hui, PIL OS sait distinguer un serveur introuvable d’une absence de réponse. Il ne sait pas expliquer cette absence : serveur éteint, message perdu ou traitement trop long produisent encore le même résultat. C’est la prochaine frontière du système, et elle est déjà visible dans ces trois mots : pas de reponse.