Mois : août 2014

Gestion des modules – IO et gros objets

Suite de l’article Gestion des modules.

L’exportation du traitement des IO dans des modules entraîne un autre problème avec les gros objets.

Les gros objets peuvent être visualisés dans le navigateur quoi qu’il arrive puisque la lecture du contenu d’un objet est faite par le navigateur et ce contenu est transmis sans traitement par le serveur web. Ce quelque soit la taille de l’objet.
Par contre, si un objet nécessite un traitement, comme le déchiffrement, alors cela ne marche plus de la même façon.

Le traitement d’un objet nécessite qu’il soit placé en mémoire de l’instance PHP en cours, avec toutes les restrictions et limites que l’on va rencontrer. Il n’est pas possible de travailler facilement comme on le ferait sur bash avec une série de ‘pipes’.

Ce problème va aussi se poser lors de la synchronisation d’un objet sur une serveur web externe, via le module IO HTTP. Avant de pouvoir l’écrire localement, via le module IO FileSystem par exemple, il devra tenir en mémoire.
Il est peut-être possible, dans le das d’échanges entre IO, de mettre en place des copies progressives d’objets pour soulager la mémoire. A voir…

Pour le déchiffrement et l’affichage, il est possible de créer une fonction spécifique. Pour le chiffrement, il va falloir travailler par blocs.

IO HTTP et performances dans PHP

Pour les besoins du module des IO sur HTTP, j’ai réalisé quelques tests afin de déterminer la meilleur méthode pour vérifier la présence d’un dossier ou d’un fichier sur un serveur web via HTTP.

La méthode la plus simple consiste à appeler l’URL de ce que l’on veut avec l’instruction file_get_contents.
C’est très simple mais très lent puisque tout le contenu est téléchargé alors que l’on ne souhaite que l’entête de la réponse du serveur. En fait, on a juste besoin de la première ligne de la réponse pour connaître le code de réponse du serveur, 200 si un fichier est disponible. 404 si le fichier n’existe pas. 403 si le fichier n’est pas accessible pour cause de restriction.
A noter que cette instruction et d’autres comme fopen nécessitent d’autoriser explicitement l’ouverture des URL avec allow_url_fopen=On et allow_url_include=On. Ces options sont nécessaires au bon fonctionnement du bootstrap, cela n’introduit donc pas de configuration supplémentaire.

La seconde méthode consiste à demander l’entête (header) via l’instruction PHP correspondante, get_headers.
Sauf que ce n’est pas mieux puisque le contenu est malgré tout téléchargé même si au final on n’extrait que l’entête.

Une autre méthode consiste à utiliser la librairie CURL dans PHP. Cette librairie est spécialisée dans les manipulations des URL, mais cela oblige à l’installer, ce qui n’est pas forcément la meilleur solution.
Par contre, en terme de performance, c’est d’un autre niveau. On peut raisonnablement savoir si un gros fichier est présent sur le serveur sans avoir de temps de latence démesuré. Au moins pour ces performances, cela peut valoir le coût d’installer cette librairie.

Enfin, une dernière solution consiste à générer soit-même la requête à transmettre au serveur et d’analyse la réponse. Cela peut être fait avec l’instruction fsockopen. Mais il faut tout faire, générer la requête, la transmettre, recevoir la réponse et la traiter.
La requête doit être du type HEAD pour n’avoir que l’entête.
Après avoir fait divers tests, cette dernière solution semble la plus rapide.

Voir les temps de réponses pour savoir si le dossier l est présent sur le serveur web local (CF code en annexe) :

 file_get_contents
 HTTP/1.1 200 OK
 2.0584919452667s

 get_headers
 HTTP/1.1 200 OK
 1.8262121677399s

 curl
 200
 0.006443977355957s

 fsockopen
 200
 0.0010509490966797s

Le dossier en question contient 24000 fichiers.
Il est clair de fsockopen est la solution la plus performante. C’est celle qui sera utilisée.

Je ne traite pas le cas des renvois type 301 puisqu’il n’est pas prévu pour l’instant dans la librairie nebule de suivre ces renvois.

Continuer la lecture de IO HTTP et performances dans PHP

Gestion des modules

La gestion des modules existait au niveau de sylabe. Elle est ajoutée directement dans nebule en PHP. Ce qui permet de l’utiliser à la fois dans nebule et sylabe. Chaque programme peut utiliser ses propres modules.

La programmation orientée objet dans PHP permet de gérer plus facilement des modules puisque ce sont simplement des classes, une par module, qui respectent des interfaces précises et non des fonctions multiples par modules. Le mécanisme de gestion derrière consiste à recenser les classes qui respectent certains critères et les lister dans un tableau, pré-instanciées.

La pré-instanciation permet d’initialiser certains environnements comme un accès à une base de donnée par exemple.

Il y a deux niveau de gestion en fait.
Le premier se fait au niveau de nebule. L’instanciation de la classe nebule va rechercher tous les objets qui sont définis comme des modules, c’est à dire avec le bon type et qui sont liés uniquement par l’entité bachue. La recherche des modules se fait en mode strict, les autres entités sont ignorées sauf les entités marquées comme autorités locales.
Le deuxième niveau, toujours lors de l’instanciation de la classe nebule, va appeler une classe spécifique par catégorie de modules. Cette classe est dite classe de routage. Pour chaque catégorie de modules, la classe de routage va s’occuper de rechercher toutes les classes correspondants à des modules ayant la même interface.

La classe de routage respecte la même interface que les classes des modules concernés. Elle seule est définit et reconnu dans l’instance nebule. Et c’est elle qui, étant appelée, va transmettre les requêtes vers la classe, le module, la plus appropriée au traitement. Elle fait donc les rôles de découverte des modules et de routage vers ces modules. Comme la classe de routage partage la même interface, elle a le même comportement que celles-ci, ce qui facilite le développement.

Il existe actuellement deux classes de routages reconnues : io et social.
La classe communication a été fusionnée dans io n’existe plus.

Il y a cependant un problème. En intégrant les IO dans des modules à charger, on se coupe l’herbe sous les pieds puisque pour charger les modules il faut avoir des IO fonctionnels… alors que ces IO sont dans les modules que l’on veut charger…
Là, le bootstrap va nous aider puis qu’il contiendra la classe d’un module IO par défaut, les IO sur système de fichier (FileSystem). Lors du chargement de la librairie nebule en php, une nouvelle détection se fera mais sur les modules présents localement, c’est à dire sur le système de fichier.

Ce fonctionnement par défaut avec le bootstrap entraîne un autre problème. Puisque l’on va utiliser le module IO FileSystem par défaut, on ne prendra en compte que ce qui y est présent. Si la libraire charge par défaut un autre module IO, par exemple MYSQL, alors les mises à jours des objets, et donc des modules, ne seront pas écrit sur le système de fichiers, et donc ceux-ci ne seront pas mis à jour.
Il faut prévoir un mécanisme de mise à jour…

Avancement

L’implémentation du bootstrap en PHP orienté objet avance. Voici à quoi ça ressemble :

shot-2014-08-20_23-44-45

Voici les classes et interfaces actuellement utilisées :

  • class nebule
  • class Object
  • class Entity extends Object
  • class Localisation extends Object
  • class Link
  • interface ioInterface
  • class ioFileSystem implements ioInterface
  • class Metrology
  • interface CryptoInterface
  • class CryptoOpenssl implements CryptoInterface
  • interface CommunicationInterface
  • class Communication implements CommunicationInterface
  • class CommunicationHTTP implements CommunicationInterface
  • interface SocialInterface
  • class SocialStrict implements SocialInterface

Il est question de fusionner les classes Communication dans les IO. Les IO sur HTTP, SMTP et XMPP seraient des IO en lecture seule. Et surtout, ce serait des modules optionnels là où un module tel que ioFileSystem serait obligatoire. A moins que tout module d’IO ne soit valable et que l’instance ne fonctionne que avec des objets et liens sur un serveur HTTP ou XMPP autre, idée à creuser…

Téléchargement et pondération – Protocols multiples

Suite des articles Téléchargement et pondération et activation.

Jusque ici, on utilise que le protocole HTTP. C’est simple, pratique et instantané.

Mais il était prévu que les objets et liens nebule puissent transiter par d’autres protocoles, notamment la messagerie.

On va prendre pour commencer le cas de la messagerie instantanée, et plus précisément XMPP qui est à la fois fonctionnel, ouvert et universel.
Contrairement à ce que l’on pourrait penser, l’utilisation de ce protocole est assez aisé. Il faut gérer une connexion TCP, transmettre des messages pré-formatés en XML et récupérer la réponse toujours en XML.
Ce qui est plus problématique par contre, c’est qu’une instance de nebule soit bidirectionnelle, c’est à dire qu’elle soit aussi serveur. Pour qu’elle puisse être serveur, elle doit fonctionner en permanence, or en HTTP, une fois la page chargée, tout s’arrête jusqu’à la prochaine page demandée.
Il faut utiliser un serveur XMPP sur lequel se connecte un autre programme. Ce programme agira comme tout client XMPP et fera la traduction vers les spécificités nebule, en gros répondre aux demandes d’objets et de liens.
Le serveur XMPP peut garder des messages pour les clients déconnectés. Pour le côté programme serveur de nebule, ça n’a pas d’intérêt, ils peuvent être supprimés lors de la connexion initiale au serveur XMPP. Par contre, côté client nebule, ce pourrait être des réponses à des requêtes précédentes. Mais si l’on respecte le sens des échanges, on ne doit accepter que les réponses correspondantes à des requêtes, et donc il faut suivre ces requêtes.

On continue avec le protocole de messagerie SMTP. Contrairement à XMPP vu précédemment, la messagerie SMTP n’est pas temps réel, c’est à dire instantanée. C’est même pire, elle a une contrainte de temps très large. Et ceci même si un message peut traverser le monde dans la seconde. Ce qui est à son avantage en temps normal est un problème dans notre cas.
On peut donc l’inclure dans les protocoles en espérant que les réponses seront rapides.
Un autre problème, c’est qu’il faut travailler avec un serveur de messagerie tiers avec deux voir trois protocoles différents. En effet, le SMTP ne sert qu’à l’envoi, la réponse doit être consultée avec POP ou IMAP.
Difficile donc d’implémenter facilement ce protocole. Il faudrait presque refaire un serveur dédié à nebule, ce qui serait plutôt improductif…

Il va falloir maintenant normaliser pour chaque protocole les requêtes/réponses.

Évidemment, la liste supportée n’est pas fermée. D’autres protocoles pourront être ajoutés par la suite…

T̩l̩chargement et pond̩ration Рactivation

Suite aux réflexions sommaires de Téléchargement et pondération, la mise en place commence dans le code de la librairie.

Cependant, le fait de créer par défaut un lien de pondération pour une localisation peut poser problème. Les liens générés peuvent être exploités comme des traces de l’activité d’une entité. C’est une façon de savoir quand une personne, à qui appartient l’entité, est connectée et de suivre les connexions dans le temps.

Il y a deux parades à ça. La première, interdire par défaut les synchronisations sauf si c’est explicitement demandé. La deuxième, c’est de ne pas ajouter automatiquement la pondération aux localisations lors des synchronisations.

La première solution est plutôt à gérer du côté d’une application de type sylabe.

La seconde solution est à intégrer dans la librairie php sous la forme d’une option.

Téléchargement et pondération

La pondération de la localisation est réalisée par un objet nebule de type spécifique. C’est une pondération de type temporel et éventuellement qualitatif (plus tard). Ce n’est pas la pondération de l’objet de localisation qui est lui définit pas l’environnement social.

La liste de téléchargement de puppetmaster va se faire sur des sous-liens pré-calculés du domaine nebule.org . Le bootstrap se basera sur cette méthode pour se télécharger.

Dans la librairie, il faut créer d’une classe d’objet pour les liens de localisation. On écrit la pondération si le site répond, et si une entité est déverrouillée.

Dans les objets, téléchargement par défaut sans préciser de site. Dans les objets de localisation, téléchargement par défaut d’un ID sur la localisation.

Il faut prévoir une synchro dure, c’est à dire partout et longue, et une douce sur un sous-groupe des localisations. Le sous groupe peut inclure des localisations qui ont les meilleurs pondération, et des localisations choisies au hasard. Cette dernière possibilité permet de renouveler régulièrement les pondérations et de ne pas se retrouver isolé, obligé de faire une synchronisation dure.

La pondération de la localisation est un nombre décimal calculé comme l’inverse du temps de réponse moyen en secondes. Une localisation sans pondération aura le poids 1.

CF : Quantification commune de la disponibilit̩s des relais Рsuite Рsuite 2

Avancement de la réimplémentation

La ré-implémentation de la librairie nebule php en orienté objet continue.

C’est plus long que prévu mais c’est intéressant. Cela oblige à refaire le tour des options et de leur pertinence avec le temps. C’est aussi l’occasion de revoir l’organisation de l’ensemble des fonctionnalités et de leurs places.

Je commence par le bootstrap puisque c’est l’implémentation la plus simple de nebule. Du coup, il ne change pas trop de forme mais il est réorganisé dans son fonctionnement. Un certain nombre de tests sont ajoutés pour vérifier le bon fonctionnement de l’ordinateur et de l’instance de nebule. Les entrées sorties sont vérifiées en lecture et écriture. Le bon fonctionnement de la cryptographie, qui se faisait jusque là dans sylabe, est aussi réalisée par le bootstrap. Le dysfonctionnement de certains tests critiques provoqueront le chargement de la page de bootstrap au lieu de l’application normale.

shot-2014-08-10_15-09-59

Le code correspondant, en cours de développement, est disponible ici :
http://stephane.nebule.fr/?mod=aff&obj=6ba665284be710117d2d2a2f81e8c9fe45d39e6fa270e54b7a515b63aa9eff3e

Lorsque le code sera intégré dans la librairie, les anciennes fonctions de la librairie procédurale seront ré-implémentées. Le code en orienté objet nécessite la connaissance de la programmation orientée objet, ce qui n’est pas à la portée de tout le monde puisque cela nécessite un temps de formation. Il faudra faire un guide d’utilisation de la librairie et de ses fonctions procédurales et orientées objet pour que n’importe qui puisse l’utiliser. Et puis, cela permettra aussi une transition facile pour le code de sylabe qui est en procédurale… et est assez volumineux pour moi à reprendre…