[API] Pocket Peripherals v1.1

Voir le sujet précédent Voir le sujet suivant Aller en bas

[API] Pocket Peripherals v1.1

Message par Kuruyia le Jeu 27 Oct - 5:59

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

Utilisation:

L'API est assez simple d'utilisation, il suffit de la télécharger, puis de l'utiliser comme une API normale.

Cet API se base sur le réseau pour pouvoir communiquer avec un serveur qui possède les périphériques, il est donc nécessaire d'avoir un modem sans fil sur le Pocket Computer.

Cette API se base sur les trois périphériques cités plus haut, pour y accéder, il suffit de faire :
wperipheral.<nom du périphérique>.<méthode>(arguments)
Par exemple, si je veut envoyer un message dans le chat, je vais taper wperipheral.chatInterface.sendGlobalMessage("Salut !")

Différentes méthodes :

wperipheral.worldInterfacewperipheral.entityDetectorwperipheral.chatInterface
getBiome
getWeather
getBlockInfos
getBlockDatatags
getRealDate
getPlayerList
getMethods
scanRegion
getColor
rawLaunch
getEntityListAdvanced
getEntityList
getPlayerDetail
getMethods
rawLaunch
sendGlobalMessage
sendPlayerMessage
setName
getName
getMethods
rawLaunch
Notez la présence de rawLaunch et de getMethods dans les trois périphériques, le premier permet d'appeler une méthode qui ne serait pas listée tandis que le deuxième rapporte tout simplement un tableau avec toutes les méthodes disponible pour le périphérique en question.

Concernant le chatInterface, le nom de la chatbox est reset 10 secondes après la dernière fonction setName envoyée.

Fichier:

État du projet : L'API est stable, le serveur est stable mais en alpha.

pastebin get fBb62NFk wperipheral

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
avatar
Kuruyia

Messages : 83
Date d'inscription : 10/04/2016
Age : 16
Localisation : Glitch City

Revenir en haut Aller en bas

Re: [API] Pocket Peripherals v1.1

Message par skypop le Sam 29 Oct - 12:14

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.
avatar
skypop

Messages : 95
Date d'inscription : 25/07/2016

Revenir en haut Aller en bas

Re: [API] Pocket Peripherals v1.1

Message par Kuruyia le Sam 29 Oct - 18:11

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:
Les points divergents :

skypop a écrit:- La compatibilité n'est pas limitée aux pocket computers, mais tout ordinateur disposant d'un modem wireless
Je voulait limiter cette API aux pocket comptuers car elle sert initialement pour les appareils mobiles n'ayant pas de possibilité d'accès physique à un de ces périphériques, mais il serait tout à fait possible de la "débrider" en rendant compatible tout appareil de ComputerCraft ayant accès au réseau sans fil, dans ce point là je n'ai rien à redire et suis OK.

skypop a écrit:- J'ai exclu l'utilisation du ChatInterface, pour des raisons de responsabilité étant donné que son utilisation est réglementée.
Effectivement, le ChatInterface est réglementé, je ne suis pas contre sa soustraction mais préférerait quand même un bridage de ses fonctionnalités, mais je comprendrai tout à fait ton choix de le soustraire purement et simplement.

skypop a écrit:- 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)
Je n'avait pas pensé à ça, mais encore une fois une simple restriction des fonctions incriminés suffirait à éliminer le problème.

skypop a écrit:- Les données renvoyées ne sont pas encryptées
J'aimerait, dans la mesure du possible, encrypter les données qui transitent entre le serveur et le client pour éviter tout espionnage des communications (ce qui est clairement ironique vu que c'est justement mon travail, d'espionner les gens).

skypop a écrit:- 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)
Pourquoi pas, mais si je comprends bien, il faudra alors donner une clé à chaque utilisateur, donc mettre en place un Computer de distribution de clés, comme tu l'a fait au spawn avec ton programme PocketScan (qui par ailleurs, est excellent !).

skypop a écrit:
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)
Effectivement, j'ai fait des tests moi aussi, et il s'avère que le serveur n'arrive pas à gérer deux requêtes lancées quasiment en même temps (il répond à une requête d'un des deux clients mais pas à l'autre), sinon, j'ai mis en place un système de "file d'attente" qui place toute les requêtes dans un tableau en attendant d'être traitées.

Points à développer:
Les points à développer :

skypop a écrit:- 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.
Idée intéressante, je suis partant pour ça.

skypop a écrit:- 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)
J'avais effectivement pensé à ça de mon côté, donc je suis OK.

skypop a écrit:- 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.
Effectivement, on pourrait instaurer une répétition de la requête (avec un espacement de 1/2 secs, car si le serveur ne peut pas répondre, cela veut peut-être dire qu'il est occupé avec une/plusieurs autre(s) requête(s)), je suis OK.

skypop a écrit:- Étendre les fonctionnalités au Nether. Auto-détection de la dimension, et paramètres optionnels (pour déterminer la dimension voulue)
Ton logiciel PocketScan le fait déjà très bien, donc on pourra réutiliser ce que tu as déjà codé.

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.
avatar
Kuruyia

Messages : 83
Date d'inscription : 10/04/2016
Age : 16
Localisation : Glitch City

Revenir en haut Aller en bas

Re: [API] Pocket Peripherals v1.1

Message par skypop le Sam 29 Oct - 19:00

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.
avatar
skypop

Messages : 95
Date d'inscription : 25/07/2016

Revenir en haut Aller en bas

Re: [API] Pocket Peripherals v1.1

Message par Kuruyia le Sam 29 Oct - 21:05

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.
avatar
Kuruyia

Messages : 83
Date d'inscription : 10/04/2016
Age : 16
Localisation : Glitch City

Revenir en haut Aller en bas

Re: [API] Pocket Peripherals v1.1

Message par skypop le Dim 30 Oct - 10:02

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.
avatar
skypop

Messages : 95
Date d'inscription : 25/07/2016

Revenir en haut Aller en bas

Re: [API] Pocket Peripherals v1.1

Message par Kuruyia le Dim 30 Oct - 11:07

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.
avatar
Kuruyia

Messages : 83
Date d'inscription : 10/04/2016
Age : 16
Localisation : Glitch City

Revenir en haut Aller en bas

Re: [API] Pocket Peripherals v1.1

Message par skypop le Dim 30 Oct - 15:41

edit : en fait rien Smile dsl
avatar
skypop

Messages : 95
Date d'inscription : 25/07/2016

Revenir en haut Aller en bas

Re: [API] Pocket Peripherals v1.1

Message par Contenu sponsorisé


Contenu sponsorisé


Revenir en haut Aller en bas

Voir le sujet précédent Voir le sujet suivant Revenir en haut


 
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum