Contexte technique et contraintes d'origine
En 2004, Jagex devait supporter des milliers de joueurs simultanés via des modems 56 kbit/s. La bande passante descendante était d'environ 5 KB/s, l'ascendante bien moindre, et chaque octet était transporté sur une unique connexion TCP, imposée par le sandbox Java des applets. Le serveur fonctionnait par cycles de 600 ms, ce qui limitait le temps disponible pour calculer la vue de chaque joueur et transmettre les mises à jour avant le tick suivant.
Chiffrement minimaliste du flux
Après l'authentification RSA, le client et le serveur établissent deux flux de chiffrement ISAAC, un pour chaque direction. Seul l'opcode du paquet est chiffré, le corps restant en clair. Le choix d’un chiffrement d’un octet réduit le coût CPU et la surcharge réseau tout en empêchant les analyseurs de paquets tiers de décoder les messages.
public void putOpcode(int opcode) {
this.putByte(opcode + this.outboundCipher.value());
}
this.currentOpcode = (this.currentOpcode - this.inboundCipher.value()) & 0xFF;
Les deux flux sont initialisés à partir d’une clé partagée de quatre entiers ; le flux serveur ajoute +50 à chaque mot pour éviter la collision de keystreams.
Structure du paquet de déplacement
Lorsqu’un joueur clique sur une case, le client exécute d’abord un A* simplifié sur la carte locale, puis construit un paquet. Le format est :
byte opcode // chiffré par ISAAC
byte length // taille du corps variable
short startX, startZ // coordonnées absolues du premier waypoint
// pour chaque waypoint supplémentaire
byte deltaX, deltaZ
byte ctrlFlag // 1 si Ctrl enfoncé, sinon 0
Le champ length vaut 4 + 2*(pathLength‑1) + 1. Ainsi, un déplacement d’un seul tile génère 7 octets au total. Jagex économise en transmettant les deltas plutôt que des coordonnées absolues : chaque waypoint supplémentaire ne coûte que 2 octets au lieu de 4, soit une réduction de 50 % par étape. De plus, seuls les coins du chemin sont envoyés ; une marche de dix cases en ligne droite ne produit qu’un waypoint final, le serveur interpolant les cases intermédiaires à l’aide de sa propre carte de collision.
Analyse d'impact et limites
Cette conception minimise la charge réseau mais impose une charge serveur élevée : le serveur doit reconstituer le chemin complet, valider chaque case contre la carte et synchroniser les positions avant le prochain tick de 600 ms. Le modèle repose sur la confiance que le client ne falsifie pas les deltas, d’où l’importance du chiffrement de l’opcode : sans lui, un client malveillant pourrait injecter des paquets malformés. Cependant, le corps non chiffré reste vulnérable à l’inspection et à la modification par un intermédiaire, ce qui était acceptable à l’époque où la plupart des joueurs utilisaient des connexions domestiques non ciblées.
En résumé, RuneScape 2004 combine une architecture client‑serveur à faible bande passante, un chiffrement ciblé de l’opcode et une compression de données basée sur les deltas. Le résultat est un jeu massivement multijoueur fonctionnant de façon fluide sur des modems 56 kbit/s, tout en conservant une logique serveur robuste capable de gérer des milliers de joueurs simultanés.
