Kiwix au jour le jour

Aller au contenu | Aller au menu | Aller à la recherche

Technologie

Fil des billets - Fil des commentaires

vendredi 1 avril 2011

Content manager: challenges and solutions

Par Kelson le vendredi 1 avril 2011, 11:03

This is the translation of my previous post in French. Thx Rupert for it.

Kiwix 0.9 has now beta status and it's time to think seriously about version 1.0. The integrated management of content is Kiwix 1.0 core functionality, namely ZIM files and search indexes. Kiwix will provide a new usage experience when downloading, sharing, organizing, deleting of different content can be done without using or installing other tools. Distribution of content will benefit if we make the Kiwix users life even simpler than today. To provide such functionalities we are currently addressing the following challenges:

  • new content can be downloaded out of Kiwix
  • the software needs to be robust and fast
  • even if a content server fails or is disconnected, the user can continue to download and share content
  • the download cost need to stay low even if the volume skyrockets
  • downloading and sharing content must be easy, even if the LAN is cut off the internet

MetalinkThe architectural solution we envision to fullfill the above requirements is to combine the specific advantages of a centralized download via FTP/HTTP (for efficiency) and decentralized P2P (for ruggedness and low cost). The standard which seems to best match the requirements is Metalink. Metalink is an XML standard for defining content by using a checksum, its sources (HTTP, FTP, magnet, Bittorrent) and priority rules on these sources. Examples for such rules are the geographic location, or simply a rating system for the mirrors. The format is still fairly young, but it is being standardized by the IETF. Compared to more traditional solutions of uniquely using HTTP, FTP or P2P, the technology combines the strengths of each while eliminate the disadvantages.

To use Metalink, the following is necessary:

  • a server capable of generating metalink files, torrent, different HTTP and FTP mirrors, etc.
  • a client that can interpret the metalink files. It will need to manage all available sources, download the best and ensure sharing.

Metalink has also some existing implementations for the server called Mirrorbrain, and for the client, called Aria2. By using them we hope to keep the implementation effort low. To verify the architectural and tool choices we will make a prototype.

Lets elaborate a little bit on the server side. Mirrorbrain is a software originally developed for openSUSE, but now used by many other large projects. It is an Apache module that allows for a given file, released a bunch of checksums, one. metalink, one. torrent, a link magnet and of course the list of mirrors that have the file, taking into account the geographic location of the clients IP address. A list of tools to know what the mirror has what file is currently available, etc. When using Mirrorbrain, we can concentrate on:

  • synchronization of mirrors with rsync
  • the "Superseed" for Bittorrent
  • possibly a Bittorrent tracker and DHT node if you do not want (only) use the trackers / public nodes.

On the client side, Aria2 is a command line client which "understands" .metalink files and manages the rest. Aria2 is therefore able to download files, and can also share files coming originally from different sources via various protocols, at the same time. It is actively developed for several years and is very light. Via its XML-RPC interface it can be controlled out of Kiwix. Exactly this interface is most likely the largest part of the implementation work.

Finally, this leads us the the last challenge we need to address: where to get the .metalink files, and therefore the available content, from? Especially if no central server is available (e.g. in some mesh network scenarios) .metalink files need to be available on the client device. The plan is to integrate .metalink files into the XML files managing the content index of Kiwix. Such an XML file then would list at the same time contents available on local storage, as well as contents available for download. In the beginning, we want to just include some default index into Kiwix. Later on index files can be shared via the same technology developped for the contents itself.

2 commentaires aucun rétrolien

vendredi 11 février 2011

Kiwix 1.0 : Quels enjeux ? Quelles solutions ?

Par Kelson le vendredi 11 février 2011, 11:37

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

Metalink 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.

aucun rétrolien