Blog/Kiwix 1.0 : Quels enjeux ? Quelles solutions ?

From Kiwix
< Blog
Revision as of 13:55, 8 January 2020 by Kelson (talk | contribs) (Created page with "''Published 11/02/2011 by ~~~'' Kiwix 0.9 a à peine entamé son cycle de ''betas'' que nous commençons en parallèle à sérieusement penser la version 1.0. Deux raisons à...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Published 11/02/2011 by Kelson (talk)

Kiwix 0.9 a à peine entamé son cycle de betas que nous commençons en parallèle à sérieusement penser la version 1.0. Deux raisons à cela : la musique s'accélère pour Kiwix car la WMF soutient activement Kiwix et nous ne voulons surtout pas "avoir la tête dans le guidon".

Kiwix 1.0 apportera comme fonctionnalité principale, la gestion intégrée des contenus (pour faire simple : fichiers ZIM et indexes de recherche). Cela signifie que le téléchargement, le partage, l'organisation, la suppression des différents contenus se fera dans Kiwix et non à l'aide de logiciels externes. Nous pensons que c'est nécessaire pour simplifier la vie de l'utilisateur, mais aussi pour favoriser la distribution des contenus.

Nous pourrions évidement implémenter et intégrer un simple téléchargement HTTP ; mais cela ne serait à notre avis pas pleinement satisfaisant. Voici les quelques défis que nous pensons nécessaires de relever :

  • Il faut que le téléchargement de nouveaux contenus soit simple et puisse se faire depuis Kiwix directement.
  • Il faut que la solution logicielle soit robuste et rapide.
  • Il faut que même si la plateforme de téléchargement ainsi que ses miroirs tombent (ou sont censurés), que l'utilisateur puisse continuer à télécharger/partager des contenus.
  • Il faut que la plateforme de téléchargement reste bon marché, même dans le cas de très nombreux téléchargements.
  • Il faut que les contenus soient téléchargeables et partageables facilement, même dans un réseau local coupé d'internet.

Pour réussir, nous voulons combiner les avantages particuliers du téléchargement centralisé via FTP/HTTP (pour l'efficacité) et du P2P... en particulier du P2P décentralisé (pour la robustesse et le bas cout). Pour toutes ces raisons, notre choix technologique s'est porté sur Metalink.

Metalink est une norme XML qui permet de définir un contenu (en particulier à l'aide d'une somme de contrôle), des sources (HTTP, FTP, magnet, Bittorent) et des règles de priorité sur les sources (en fonction de la location géographique par exemple, ou tout simplement avec l'aide d'un système de note pour les miroirs). Le format est assez jeune encore, mais il est en cours de normalisation par l'IETF. Les avantages de Metalink sont clairs par rapport à des solutions plus traditionnelles uniques comme HTTP, FTP ou le P2P ; cette technologie permet de combiner les points forts de chacune d'entre elles tout en élimant les désavantages.

Pour utiliser Metalink, il faut :

  • une solution serveur capable de générer les fichiers .metalink, .torrent, les différents miroirs HTTP et FTP, etc. et
  • une solution client capable d'interpréter les fichiers .metalink, de gérer toutes les sources disponibles, de télécharger au mieux ainsi que d'assurer le partage.

La solution serveur s'appelle Mirrorbrain. Mirrorbrain est un logiciel développé à l'origine pour openSUSE, mais utilisé aujourd'hui par de nombreux autres gros projets. Mirrorbrain, c'est plusieurs choses :

  • un module pour Apache qui permet, pour un fichier donné, de sortir tout un tas de sommes de contrôle, un .metalink, un .torrent, un lien magnet et naturellement la liste des miroirs qui disposent du fichier en tenant compte de la localisation géographique du client (localisation par IP),
  • une liste d'outils pour savoir quel miroir possède quel fichier, est actuellement disponible, etc.

En utilisant Mirrorbrain, il ne nous restera à gérer:

  • la synchronisation des miroirs avec rsync,
  • le "superseeder" pour Bittorrent,
  • éventuellement un tracker Bittorrent et noeud DHT si on ne souhaite pas (seulement) utiliser les trackers/noeuds publics.

L'introduction de Mirrorbrain devrait donc être assez vite réalisée ; dans les faits elle est déjà bien entamée.

Coté client, la meilleure solution qui nous soit accessible se nomme Aria2. Aria2 est un logiciel de téléchargement en ligne de commande qui comprend les fichiers .metalink et gère tout. Aria2 est donc capable de télécharger, et partager lorsque c'est possible, en parallèle un même fichier depuis différentes sources et en utilisant différents protocoles. Il est activement développer depuis plusieurs années et est très léger. Il dispose d'une interface XML-RPC permettant de le contrôler depuis Kiwix. Là se trouve probablement le plus gros du boulot ; Il nous faudra rapidement faire un prototype pour valider ce choix.

Le dernier point en suspend semble être alors la question de la disponibilité des fichiers .metalink ; en-effet, que faire si les fichiers .metalink sont indispensables et que le serveur central est indisponible ? Notre idée est d'intégrer les .metalink dans les fichiers XML gérant la bibliothèque de Kiwix. Un tel fichier pourrait donc indistinctement lister des contenus présents sur la mémoire de masse, comme des contenus disponibles en ligne au téléchargement.

La question ultime concernerait alors la mise à disposition des ces fichiers bibliothèque. Un début serait déjà de les livrer par défaut avec Kiwix. Dans tous les cas de figures, distribuer un fichier de quelques milliers de kilooctets est bien moins problématique que de distribuer les contenus en eux mêmes qui font plusieurs gigaoctets.