Interface par défaut de serveurs

Une nouvelle interface est terminée, elle concerne les serveurs en php. Cette interface s’appelle nServ et ressemble à ça :

nServ_-_2014-09-21_15.23.20

Elle peut être simplement définit comme étant l’application par défaut en utilisant le bootstrap classique. Elle peut aussi, si on n’implémente pas php, et donc pas de bootstrap, être présente comme fichier par défaut index.html avec les informations écrites directement dans la page et non générées automatiquement. Dans ces informations, on retrouve le nom public de l’entité, son identifiant et quelques informations sur nServ et sa licence.

A noter que le nom est ici celui de mon entité, mais se sera à terme normalement celui d’une entité de serveur…

Transfert de liens et de confiance

Les réseaux fragmentés posent des problèmes plus importants que le maintient de la cohérence du système d’horodatage. CF Gestion temporelle partielle.

Certains protocoles de sécurisation des échanges deviennent bancales sans synchronisation de temps. Mais il y a plus grave. La cohérence du temps entre plusieurs machines peut être négligé sur une courte période, les horloges ne vont pas dériver exagérément et il y a peu de change que des certificats expirent. Par contre, il devient difficile de transmettre de nouveaux contacts avec un grand niveau de confiance. les relations de confiance sont souvent dépendantes de services centralisés, services qui ne sont plus forcément joignables. Ces services ont le rôle d’annuaires globaux. Il faut dans ce cas faire confiance aux seuls intermédiaires que l’on a sous la main, et que l’on connaît (au moins dans nebule). On doit utiliser des entités comme des annuaires locaux.

Dans ce cas, il est peut-être utile de voir si la définition d’un nouveau type de lien ne pourrait pas répondre à ce besoin. Ce serait un lien signé par une entité que l’on connaît et qui transmettrait un lien d’une autre entité, inconnue. Un lien serait encapsulé dans un autre de la même façon que pour un lien offusqué. La validité et la pondération du lien de l’entité inconnue seraient les mêmes que si le lien venait de l’entité connue. Ce serait une forme de relais de liens.

Ce type de lien aura peut-être aussi une utilisé pour les annuaires d’entités. Cela pourrait faciliter la mise en relation entre deux entités qui ne se connaissent pas.

Mais, c’est aussi un risque qui faut analyser. On commence dans ce cas à prendre en compte des liens d’une entité que l’on ne connaît pas et que l’on ne peut directement vérifier. Il faut voir ça comme si l’entité qui fait le relais des liens s’appropriait elle-même le lien. Cette entité peut diffuse des liens invalides, c’est à dire dont la signature est invalide, sans que l’on puisse le vérifier. L’affiche de ces liens ou leur interprétation doit être peut-être adapté pour montrer cette particularité…

Marque de temps

Il est maintenant clair qu’il faut aller plus loin que la norme ISO8601. Il faut que le code soit capable d’interpréter différents calendriers connus ou pas, par extension. Dans ces calendriers pourront prendre place une référence de temps en temps long tel que le calendrier Maya.

CF : Gestion temporelle partielle, Horodatage, ISO 8601, suite et Marque de temps.

Gestion temporelle partielle

Il y a deux façons de gérer le temps et deux façons pour le prendre en compte.

C’est la suite des articles Horodatage, ISO 8601, suite et Marque de temps.

La référence de temps, ou pas

On peut gérer le temps comme étant un prérequis commun à tous les acteurs. Dans ce cas, toutes les machines doivent synchroniser leurs horloges internes sur une source commune. Tout le monde travaille avec la même heure, le même espace temps et la même référence. Ici on ne tient pas compte du fuseau horaire qui est un bricolage de décalage non pas temporel mais sur l’affichage uniquement. Aujourd’hui, l’orientation de tous les systèmes d’informations, c’est la synchronisation globale, c’est à dire la même partout sur la planète.
On pourrait aussi simplement considérer que chaque machine, chaque utilisateur, a un espace temps qui lui est propre. Pas de synchronisations à faire mais se pose alors l’interprétation d’une date donnée par une autre machine. Il faut prévoir un mécanisme de correction du temps des autres machines, par rapport à une référence. On retrouve cette référence commune mais elle peut dans certains cas être soi-même, c’est à dire je suis à la bonne heure et je compense l’heure des autres. En cas d’absence de référence externe, il faut retenir le décalage de chacune des machines avec lesquelles on communique.
Avoir une référence commune implique une communication régulière avec cette référence. Il faut donc une connexion réseau, même partielle. Plus la précision attendue dans la synchronisation est forte, plus les moyens tant en réseau qu’en relais doivent être importants, rapides et fiables. Sur des réseaux isolés ou fortement fragmentés, la synchronisation du temps devient illusoire. Et cela peut arriver partout sur la planète : catastrophe naturelle, guerre, dictature, repli sur elles-même des nations, etc…

Le problème sur la référence de temps n’est pas que théorique. Ce ne serait pas « juste un problème d’affichage ». Beaucoup de protocoles de sécurisation s’appuient aujourd’hui sur le temps et exigent un horodatage assez précis. Lorsque l’on se connecte au site web de sa banque, lorsque l’on renvoie un message signé, lorsque l’on se connecte à un réseau d’entreprise, les jetons de session et autres certificats électroniques ont une durée de vie limitée ou une date d’expiration. Tous ces services impliquent d’avoir un réseau pour fonctionner et peuvent délivrer une référence de temps en même temps que ces services. Par contre, des documents comme les passeports sont aussi émis avec une date d’expiration et il serait difficile de vérifier leur validité sans une référence de temps commune.

Le système de gestion du temps dans nebule est encore aujourd’hui basé sur l’horloge interne de la machine qui exploite les liens. Il utilisera aussi l’entité kronos comme référence. Mais il est prévu de calculer et mémoriser les décalages de temps entre machines. Cette capacité à mémoriser les variations de temps rend l’ensemble plus résilient en cas de catastrophe ou tout simplement de fragmentation volontaire des réseaux. A faire…

Sur un réseau maillé comme sur Internet, la structure globale ressemble à un fractal dans lequel on peut zoomer et retrouver les mêmes formes de connexions entre nÅ“uds de réseau. Un réseau Internet fragmenté serait sûrement toujours maillé et toujours interconnecté, mais la structure globale ressemblerait plutôt à une nébuleuse, c’est à dire sans structure marquée. Dans ce deuxième cas, les synchronisations de temps seraient souvent conflictuelles.
Le postulat que l’on peut simplement synchroniser tout le monde sur une seule et unique référence de temps est une facilité de notre époque. Mais c’est une facilité qui n’est ni évidente ni définitivement acquise.

Prise en compte des événements futurs, ou pas

Avec synchronisation du temps entre les machines ou pas, il peut arriver d’une marque de temps soit dans le futur ou interprétée comme telle. Que fait-on dans ce cas ? Est-ce une erreur de l’émetteur ? Est-ce une erreur de synchronisation ? Est-ce une erreur de zone de temps ? Est-ce un acte malveillant ?
Et c’est pareil pour une date du passé qui ne correspond manifestement pas à l’ère informatique. Est-ce une erreur de référence de temps ?

On peut tenir compte d’une marque de temps problématique et l’interpréter telle quelle vis-à-vis des autres date. Dans le cas d’une suppression de lien marqué dans le futur, cette suppression est valable. Mais, parce qu’elle est dans un futur un peu lointain, il va devenir impossible de réhabiliter ce lien avant cette date puisque sa suppression sera toujours valide temporellement. Il faudrait un nouveau lien plus loin dans le futur qui, lui, empêcherait la suppression avant cette nouvelle date dans le futur… On ne s’en sort pas.

On peut ne pas tenir compte d’une marque de temps invalide et l’écarter du traitement comme étant incohérente. Dans ce cas un lien de suppression dans le futur ne serait plus utilisé avant que notre espace temps ne soit arrivé effectivement à cette date.
Mais dans ce cas la synchronisation de temps ou l’utilisation d’une référence de temps a beaucoup plus d’importance puisque des dates du calendrier arabe, hébraïque, indien, chinois ou copte n’ont pas la même signification. Des événements interprétés comme étant dans le futur seront automatiquement ignorés alors qu’ils sont peut-être valides.

La non prise en compte de liens avec une date dans le futur semble la meilleur solution, mais elle n’est pas encore implémentée dans nebule. A faire…
L’implémentation doit aussi permettre de gérer sereinement les décalages, prévisibles, du temps entre différentes machines même si elles ont la même référence de temps. En dessous de la seconde, une synchronisation globale est illusoire. Avec une connexion à Internet intermittente, une précision de l’ordre de la minute est plausible. Il faut donc prévoir un paramètre afin de définir le décalage maximal de temps que l’on accepte pour des liens dans le futur.

L’utilisation de la norme ISO8601 est indispensable mais pas suffisante. Tous les calendriers n’utilisent pas cette forme et bien sûr n’ont pas la même référence de temps. De plus, si il permet une grande précision, il ne permet pas de manipuler le temps sur ce que l’on appelle le temps long. Il serait intéressant de pouvoir manipuler d’autres calendriers, peut-être avec un préfixe spécifique.

Lien juste à temps

Les liens de nebule n’ont pas vocation à permettre un traitement complexe des données, juste à permettre leur transmission et faciliter le traitement.

Manipuler des données avec des échéances n’est possible qu’en associant un objet contenant une date avec un objet méta spécifique. Le traitement à échéance est réalisé par le programme qui interprète cette forme de lien. Il est facile de réaliser au niveau des liens d’une prise en compte « Ã  retardement » d’un lien. Le modèle pourrait être l’encapsulation d’un lien dans un autre lien d’un type particulier, sur le modèle du lien offusqué. Au lien d’une clé de chiffrement, ce pourrait être une date de prise en compte.
Ce nouveau type de lien est de fait en concurrence avec un lien avec une date dans le futur. Mais cela présenterait quand même quelques avantages. Le premier, c’est que la date pourrait être aussi une période de prise en compte. Mais surtout, là où un lien dans le futur pourrait être supprimé parce que considéré invalide, un lien dédié à cet usage serait beaucoup plus légitime.

Cette idée est encore à réfléchir…