[API] Pocket Peripherals v1.1

Une API qui vous permet d'utiliser Chat Interface/Entity Detector/World Interface sur votre pocket computer !

Utilisation:

Fichier:

Veuillez ne pas bombarder le serveur de requêtes inutiles, tout abus du service amènerait à un ban de l'ID, tout est loggé.

Remerciements :
- Thomasims, à qui j'emprunte son API de cryptage.

Changelog :
Version 1.1 :
+ Gestion des erreurs serveur
Version 1.0 :
+ Release

Je travaillais sur un projet similaire, achevé et effectif. Je l'ai mis en pause dans l'intention de publier mon programme PoketScan avant, et ne l'ai pas mis à jour depuis l'ajout de la methode scanRegion (du WorldInterface)

Quelques points divergents :
- La compatibilité n'est pas limitée aux pocket computers, mais tout ordinateur disposant d'un modem wireless
- J'ai exclu l'utilisation du ChatInterface, pour des raisons de responsabilité étant donné que son utilisation est réglementée.
- Certaines fonctionnalités sont restreinte, lorsque la fonction est relative à la position des interfaces, et non celle du PC. (ex: getEntityList() sans préciser de coordonnées)
- Les données renvoyées ne sont pas encryptées
- Un système de clés utilisateurs, et un clé publique afin de logguer d’éventuels abus d'utilisation (fonctionalité que j'envisageais de faire sauter)

J'ai effectué un bon nombre de stress-test, et un seul serveur était capable d'atteindre un taux de réponse supérieur à 256/s (et davantage en désactivant le principe de clés utilisateur)

Points que j'envisageais de développer :
- de fournir le programme du serveur aux joueurs ayant développé un business d'hébergement, afin de proposer à leur clients un service de serveurs dédiés.
- Remanier les fonctions peripheral.find() et peripheral.wrap() pour qu'un WorldInteface et un EntityDetector à proximité reste prioritaire, que l'utilisation de l'API soit un ultime recours si un modem wireless est équipé. ça apporte aussi l'intérêt qu'il n'est pas nécessaire de modifier les programme (du moment que l'API est initialement chargée)
- Adjoindre au timeout une répétition de la requête en cas de non-réponse. Càd répéter 2-3 fois la requête si le serveur n'est pas disposé à répondre avant d'échouer sur un timeout. ça permet que l'abus ne soit plus un problème, tant qu'il est ponctuel.
- Étendre les fonctionnalités au Nether. Auto-détection de la dimension, et paramètres optionnels (pour déterminer la dimension voulue)

Est-ce que tu serais partant pour confondre nos deux projets, et le développer en open-source ? Si oui, à quelles conditions ? (ref aux points divergents) Ou si on peut négocier sur certains détails ? (ex: l’encryptions des données pourrait être optionnel, au choix de l'utilisateur)

Sinon je poursuivrai ce projet en "concurrent", laissant le choix à l'utilisateur.
Quand bien même on ne parviendrait pas à s'accorder sur un projet commun, tu es le bienvenu dans mon chunk loadé du Nether, pour y héberger un serveur.

Note: pour détecter dans quelle dimension on se trouve il suffit de se baser sur la distance renvoyée à la réception du modem. Si la variable est nil, c'est que le serveur et le client ne sont pas dans la même dimension.

Tout d'abord, merci de ta réponse, complète comme d'habitude, et effectivement, le projet de confondre ces deux programmes me semble être une bonne idée, donc c'est avec joie que j'accepte ta proposition, maintenant, je vais commenter les différents points que tu as évoqué ci-dessus :

Points divergents:

Points à développer:

Donc oui, je suis partant pour confondre les deux projets et le développer en open-source, tout est dit dans les différents points que j'ai commentés dans les spoilers.

Merci encore de ta réponse et de prendre le temps de lire la mienne.

Quelques précisions :

Sur le principe de clés utilisateurs. J'avais prévu une clé publique (très simple à retenir, et attribuée par défaut) que tout le monde peut utiliser, en acceptant qu'à base de cette clé le service serait moins performant. Une clé privée peut être attribuée à la demande, en échange de meilleures performance.

Enfin, au terme du développement du PocketScan, j'étais prêt à abandonner cette fonctionnalité.

Le fait de logger les échanges fait baisser considérablement les performances. J'ai cherché à améliorer ce principe. à l'origine le serveur enregistrait chaque requête dans un fichier log. J'ai exclu d'emblée le recours à un système de coroutine ou parallel, car ça n'est pas un véritable multi-threading, les fonctions avancent quand l'autre est "yield".
Du coups j'ai employé un second PC équipé d'un modem et à l'écoute du même canal pour enregistrer ces logs indépendamment du programme du serveur qui traite les requêtes et y répond. Ce que j'ai constaté est que ça reviens au même. Quand le PC en charge des logs est allumé, le serveur ralentis, et le serveur répond plus vite si le PC des logs est éteint. J'en ai conclu que j'avais juste reporté le problème au thread général de LUA sur le serveur..

J'ai optimisé mon programme de Server au maximum et réduit les pauses au strict minimum (à l'aide d'un timer, il fait au moins une pause d'un tick toutes les 30 sec (en fait je ne sais plus exactement quel délai))
Je pars du principe que c'est os.pullEvent() qui régulera les pauses nécessaires. Plus vite les requêtes sont traitées, plus vite le serveur retrouvera le repos.

Dans l'idée de conserver des logs, j'ai mis en place un buffer. Les entrées sont stocké dans une table, et sont rajoutées par paquet toutes les 30sec environ. C'est l'accès aux fichiers (API Fs) qui ralentis les performances.

J'ai envisagé de créer un buffer pour stocker les requêtes en attente de traitement, mais je n'ai pas réussi à le faire. En fait, je ne vois pas comment ça pourrait fonctionner, dans ma logique où au cours du traitement d'une requête il n'y a aucun délai qui permettrait à une coroutine d'avancer. D'où mon idée, qu'en cas de non-réponse la requête soit répétée 2-3 fois.

Concernant l'encryption, j'adhère à l'idée sur le principe, je crains juste que ça n'alourdisse le traitement des requêtes, et donc ralentisse leur traitement.
D'autre part, toutes les données ne sont pas "sensibles" : getRealDate(), getPLayerList(), etc...
D'où mon idée que l'encryption soit optionnelle (voire dédiée à un second serveur)

Il faut que je me remette dans le bain. Quand j'ai mis ce projet en pause, j'étais en train de développer une fonction qui faisait le taf de scanRegion() (arrivée plus tard...)
Est-ce que tu pourrais me faire parvenir ton programme du serveur ? Je tâcherais de mettre à jour mon programme et faire la synthèse avec le tiens. Après quoi, on pourrait le tester sur le terrain et poursuivre le développement.

OK, donc du coup, pour ce principe de clés utilisateurs, ça reste à voir.

Le problème est que le fait de ne pas faire de logs reste problématique car on ne pourrait pas voir les éventuels computers qui s'amuseraient à bombarder le serveur de requêtes.

Concernant l'encryption, effectivement cela ralentit fortement la vitesse de traitement des données (dû notamment au fait que l'API encrypte les messages via Internet), j'ai fait quelques tests, avec encryption mon serveur est extrêmement lent (~6 opérations/s), par contre sans encryption mon serveur est beaucoup plus rapide (~250 opérations/s), il va à peu près à la même vitesse que tu as mesurée.
Je ne pense pas que donner l'encryption à un second serveur aura de l'impact sur le temps entre l'envoi et la réception de la requête du client, cela permettra de reposer le serveur principal (je suppose que ton second serveur servira aussi à l'envoi des données cryptées).
Donc effectivement, pourquoi pas rendre l'encryption optionnelle dans le cas où les données qui doivent être reçu du serveur seraient trop importantes aux yeux du joueur.

Je t'ai donné le programme du serveur quand tu était connecté sur le serveur Minecraft tout à l'heure.
J'attends ta réponse mais malheureusement la fin des vacances approchant, je n'aurait plus beaucoup de temps de jeu durant les périodes scolaires.

Concernant les logs, je partage ton avis. Venant de la programmation PHP, j'ai tendance à être très vigilant à la limite de la parano... à l'origine je craignais surtout de gros lots de requêtes getBlocKInfos, à l'ajout de scanRegion ce risque est en partie écarté. Bien que ça n'exclu pas d'éventels abus de getBlockdatatags, getEntityList, getEntityListAdvanced...
Je dirais que le système de log reste à prévoir, mais il pourrait être activable/désactivable. Ainsi, on pourrait l'activer en cas de suspicion d'abus, pour identifier un problème. Enfin, je ne me souviens plus quelle performance j'étais parvenu à atteindre en révisant mon système de logs (avec buffer), mais c'est possible qu'il permette de maintenir un rendement de 256 requêtes-réponse/sec

arc13 a écrit:(je suppose que ton second serveur servira aussi à l'envoi des données cryptées).

Oui c'est tout à fait ça : un second serveur, indépendant, et à l'écoute d'un canal différent.

Côté client il s'agirait d'un choix entre deux canaux :
- un rapide non sécurisé
- un + lent, + sécurisé

D'autre part, faut voir voir exactement quelles infos pourraient nécessiter d'être cryptées. De manière générale, je pense que c'est lorsque les données d'un objet (bloc ou entité) peut contenir ses coordonnées (X,Y,Z), ou i ces coordonnées sont transmises dans la requête :

getBiome
getWeather
getBlockInfos
getBlockDatatags
getRealDate
getPlayerList
getMethods
scanRegion
getColor

getEntityListAdvanced
getEntityList
getPlayerDetail
getMethods

En rouge, les données potentiellement sensibles.
En vert, les données non-sensibles.

getBiome est peu sensible à mon avis.
getPlayerDetail Je me demande s'il faut considérer comme sensible. L'éventuel pirate n'a pas besoin d'espionner le serveur pour obtenir ces données. Cependant ce qui peut l'intéresser, c'est vers quelles coordonnées l'appel à cette fonction est exécutée. Par exemple, si cette fonction est utilisée pour déverrouiller une porte cachée...

Une autre conclusion que j'avais oublié : Si l'utilisateur estime que les données sont sensibles, le moyen le plus fiable pour lui serait d'utiliser son propre WorldInterface ou EntityDetector via un réseau filaire. Enfin, seulement pour une utilisation via PC. Le modem wireless reste la meilleure option (si ce n'est la seule), via une turtle, un pocket computer ou les lunettes LIP.

Côté disponibilités, moi c'est l'inverse, je n'aurais pas de temps cette semaine. On pourra faire le point le week-end.

Note:
getPlayerDetail() sur un joueur connecté peut renvoyer nil, lorsque le joueur et l'EntityDetector ne sont pas dans la même dimension.

OK je pense donc que tout est bon, le problème principal reste la disponibilité, je serait là uniquement quelques samedis durant la période scolaire.

edit : en fait rien dsl