115 lines
5.4 KiB
Markdown
115 lines
5.4 KiB
Markdown
Protocole de NetworkAPI
|
|
====================
|
|
Ce fichier défini simplement le fonctionnement du protocole qui sera implémenté dans le package `net.mc_pandacraft.java.plugin.pandacraftutils.network_api`
|
|
|
|
Il servira à faire communiquer le serveur Minecraft avec l'interface d'administration ou le site internet
|
|
|
|
## Type de connexion
|
|
Connexion TCP
|
|
|
|
|
|
## Cryptage
|
|
Les communications devant rester dans un réseau privé (loopback, VNP) entre les systèmes composant le serveur, il n'est pas vraiment nécessaire de crypter les connexions. En d'autres termes, les clients effectuant les requêtes ne correspondent pas aux utilisateurs finaux, se trouvant sur les réseaux d'accès.
|
|
|
|
## Sécurité
|
|
Même si le cryptage ne semble pas nécessaire, il faut tout de même sécuriser avec un système de "mot de passe", qui sera décrit en dessous
|
|
|
|
## Structure d'une requête
|
|
La requête est construite en mode texte, sur plusieurs lignes. Chaque ligne se fini par un '\n' :
|
|
|
|
- Mot de passe alphanumérique + '\n'
|
|
- Commande principale + '\n'
|
|
- Longueur des données, en octets + '\n'
|
|
- Valeur/données (pas de '\n' à la fin)
|
|
|
|
Pour que l'analyse de la requête puisse s'effectuer côté serveur, le flux qui va du client vers le serveur doit être fermée après envoi des données.
|
|
|
|
### Exemple de paquet
|
|
ervg1e3r2c
|
|
command
|
|
12
|
|
say Salut :)
|
|
|
|
|
|
### Les commandes principaux
|
|
|
|
#### `command`
|
|
Exécute la commande passée dans la partie **donnée** de la requête, comme si elle avait été exécutée par la console (`ConsoleCommandSender` dans Bukkit). Le résultat de l'exécution de la commande (valeur de retour de CommandExecutor.onCommand()) ne peux pas être retourné en réponse. Cependant, la non exécution de la commande sera indiqué dans la console du serveur
|
|
|
|
#### `command_async`
|
|
Pareil que `command` mais cette fois, celle-ci n'est pas forcément exécutée dans le thread principal. Attention : certaines commandes ne peuvent pas fonctionner en asynchrone. Cette méthode est utile dans le cas où le thread principal ne répond plus
|
|
|
|
#### `broadcast`
|
|
Affiche un message sur le chat pour tout le monde connecté.
|
|
Le message passé dans la partie **donnée** est diffusé en convertissant les codes couleurs `&x` en `§x`
|
|
|
|
#### `chat_send`
|
|
Affiche un message en tant qu'un joueur donné, sur le chat du serveur
|
|
La partie **donnée** de la requête contient d'abord le pseudo du joueur concerné, suivi d'un espace, suivi du message. Aucun espace ne peut se trouver dans le pseudo.
|
|
|
|
#### `player_list`
|
|
Renvoi la liste des joueurs connectés, avec quelques infos utiles.
|
|
|
|
Si la partie **donnée** de la requête contient `op` et seulement ça (c'est à dire que `data.trim().equalsIgnoreCase("op")` doit être vrai), la liste des joueurs contiendra
|
|
aussi les joueurs vanish. Sinon, les joueurs vanish ne seront pas inclus dans la liste retournée
|
|
|
|
La première ligne de la réponse sera de la forme `5/30` avec le premier nombre représentant le nombre de joueur retourné, et le deuxième nombre étant le nombre de slots disponible sur le serveur.
|
|
|
|
Ensuite, une ligne pour un joueur. Chaque ligne, commençant par un `\n`, aura cette forme :
|
|
|
|
Pseudojoueur\0§f[§4Admin§f]§4Pseudojoueur§r\01\0creative\020\020\01
|
|
|
|
Chaque information sur une ligne sera séparé par un `\0` représentant le caractère NULL. Les informations données sont les suivantes :
|
|
|
|
1. Pseudo réel du joueur (répondant à la regex `[A-Za-z0-9_]{2,16}`)
|
|
2. Pseudo du joueur tel qu'il est affiché IG (avec le préfixe et le suffixe, + éventuellement un nickname, et les codes couleurs de la forme `§x`)
|
|
3. `1` si le joueur est actif, `0` si il est AFK.
|
|
4. Gamemode du joueur
|
|
5. Point de vie arrondi à l'unité
|
|
6. Point de faim arrondi à l'unité
|
|
7. `1` si le joueur est visible, `0` si il est vanish.
|
|
|
|
#### `private_message`
|
|
Envoi un message à un joueur connecté, en tant qu'un autre joueur donné.
|
|
La partie **donnée** de la requête contient d'abord le pseudo du joueur source, suivi d'un espace, suivi du pseudo du joueur cible, suivi d'un espace et enfin suivi du message. Les pseudos ne peuvent pas contenir d'espace.
|
|
|
|
marcbal toto salut :)
|
|
|
|
Cet exemple enverra de la part de `marcbal` le message `salut :)` à `toto`.
|
|
|
|
#### `console_command_history`
|
|
Retourne la liste des commandes se trouvant dans l'historique. Cette liste servira à l'interface Web pour aider à l'exécution des commandes.
|
|
|
|
La partie **donnée** de la requête ne contient rien.
|
|
|
|
Chaque ligne de la réponse sera une commande de l'historique, sachant que la dernière retournée sera la plus récente. Les doublons sont ignorés. C'est à dire que si une commande déjà existante l'historique est réexécutée, elle sera retirée de son ancien emplacement pour aller à la dernière place.
|
|
|
|
Les commandes ajoutés à cette liste seront les commandes envoyés via les requêtes `command` et `command_async`.
|
|
|
|
## Structure d'une réponse
|
|
La réponse est construite en mode texte, sur plusieurs lignes. Chaque ligne se fini par un '\n' :
|
|
|
|
- Status de réponse (`OK` ou `ERROR`) + '\n'
|
|
- Longueur des données
|
|
- Données, si nécessaire,ou message d'erreur, si status != `ok`
|
|
|
|
### Exemple de paquets
|
|
Réponse à une requête sans résultat qui a bien été exécuté
|
|
|
|
OK
|
|
0
|
|
----
|
|
Réponse à une commande inexistante
|
|
|
|
ERROR
|
|
24
|
|
command_not_exists
|
|
----
|
|
Réponse à une requête de type `player_list`
|
|
|
|
OK
|
|
52
|
|
1/30
|
|
marcbal\0§f[§4Admin§f]§4marcbal§r\01\01;20;20\01
|
|
|