80 lines
3.0 KiB
Markdown
80 lines
3.0 KiB
Markdown
|
Protocole de NetworkAPI
|
|||
|
====================
|
|||
|
Ce fichier d<>fini simplement le fonctionnement du protocole qui sera impl<70>ment<6E> dans le package `net.mc_pandacraft.java.plugin.pandacraftutils.network_api`
|
|||
|
|
|||
|
Il servira <20> 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<69> (loopback, VNP) entre les syst<73>mes composant le serveur, il n'est pas vraiment n<>cessaire de crypter les connexions. En d'autres termes, les clients effectuant les requ<71>tes ne correspondent pas aux utilisateurs finaux, se trouvant sur les r<>seaux d'acc<63>s.
|
|||
|
|
|||
|
## S<>curit<69>
|
|||
|
M<EFBFBD>me si le cryptage ne semble pas n<>cessaire, il faut tout de m<>me s<>curiser avec un syst<73>me de "mot de passe", qui sera d<>crit en dessous
|
|||
|
|
|||
|
## Structure d'une requ<71>te
|
|||
|
La requ<71>te est construite en mode texte, sur plusieurs lignes. Chaque ligne se fini par un '\n' :
|
|||
|
|
|||
|
- Mot de passe alphanum<75>rique + '\n'
|
|||
|
- Commande principale + '\n'
|
|||
|
- Longueur des donn<6E>es, en octets + '\n'
|
|||
|
- Valeur/donn<6E>es (pas de '\n' <20> la fin)
|
|||
|
|
|||
|
Pour que l'analyse de la requ<71>te c<>t<EFBFBD> serveur puisse s'effectuer c<>t<EFBFBD> serveur, le flux qui va du client vers le serveur doit <20>tre ferm<72>e apr<70>s envoi des donn<6E>es.
|
|||
|
|
|||
|
### Exemple de paquet
|
|||
|
ervg1e3r2c
|
|||
|
command
|
|||
|
12
|
|||
|
say Salut :)
|
|||
|
|
|||
|
|
|||
|
### Les commandes principaux
|
|||
|
|
|||
|
#### `command`
|
|||
|
Ex<EFBFBD>cute la commande pass<73>e dans la partie **donn<6E>e** de la requ<71>te, comme si elle avait <20>t<EFBFBD> ex<65>cut<75>e par la console (`ConsoleCommandSender` dans Bukkit). Le r<>sultat de l'ex<65>cution de la commande (valeur de retour de CommandExecutor.onCommand()) ne peux pas <20>tre retourn<72> en r<>ponse. Cependant, la non ex<65>cution de la commande sera indiqu<71> dans la console du serveur
|
|||
|
|
|||
|
#### `command_async`
|
|||
|
Pareil que `command` mais cette fois, celle-ci n'est pas forc<72>ment ex<65>cut<75>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<63>.
|
|||
|
Le message pass<73> dans la partie **donn<6E>e** est diffus<75> tel quel dans le chat et sur la console (attention <20> la bonne utilisation des codes couleurs)
|
|||
|
|
|||
|
#### `player_list`
|
|||
|
Renvoi la liste des joueurs connect<63>s. La valeur pass<73> dans la partie **donn<6E>e** doit contenir, selon les besoins :
|
|||
|
|
|||
|
- `disp_name` pour donner les noms d'affichage du genre [Admin]Pseudo
|
|||
|
- `location` pour donner la localisation du joueur
|
|||
|
- `ip` pour donner l'IP du joueur
|
|||
|
- ...
|
|||
|
|
|||
|
## 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<6E>es
|
|||
|
- Donn<6E>es, si n<>cessaire,ou message d'erreur, si status != `ok`
|
|||
|
|
|||
|
### Exemple de paquets
|
|||
|
R<EFBFBD>ponse <20> une requ<71>te sans r<>sultat qui a bien <20>t<EFBFBD> ex<65>cut<75>
|
|||
|
|
|||
|
OK
|
|||
|
0
|
|||
|
----
|
|||
|
R<EFBFBD>ponse <20> une commande inexistante
|
|||
|
|
|||
|
ERROR
|
|||
|
24
|
|||
|
command_not_exists
|
|||
|
----
|
|||
|
R<EFBFBD>ponse <20> une requ<71>te de type `player_list`
|
|||
|
|
|||
|
OK
|
|||
|
56
|
|||
|
player\0disp_name
|
|||
|
marcbal\0<>f[<5B>4Admin<69>f]<5D>4marcbal<61>r
|
|||
|
|