Salut la commu,
Étant développeur solo et gérant un catalogue de partage DDL francophone, je me suis retrouvé face à un problème assez classique : avec le temps, les fichiers disparaissent des différents hébergeurs et les liens deviennent rapidement obsolètes.
Quand on gère un catalogue important seul, vérifier et remplacer manuellement chaque lien devient rapidement impossible.
J’ai donc développé Immorta Link, un système automatisé en PHP qui fonctionne avec des tâches CRON et une machine à états. L’objectif est de limiter au maximum les interventions manuelles et de maintenir automatiquement les miroirs disponibles dans le catalogue.
Comment ça fonctionne ?
Le système travaille en plusieurs étapes.
Tout d’abord, il analyse les posts du catalogue et détecte les liens sources pris en charge. Lorsqu’un post doit être traité, il crée un job dédié. Lorsqu’un post contient plusieurs liens, chaque lien peut être traité indépendamment afin d’éviter qu’un problème sur une saison ou un fichier bloque les autres.
Le fichier source est ensuite récupéré via TorBox, qui sert notamment de source intermédiaire pour alimenter les différents remote uploads.
À partir de cette source, le système peut construire plusieurs miroirs automatiquement :
Up-4ever
MixLoads
Multiup
et TorBox lui-même comme source/miroir intermédiaire.
Les uploads distants sont traités de manière asynchrone. Le script conserve l’état du job en base de données et effectue régulièrement des vérifications pour savoir si l’upload est terminé, si le fichier est encore en cours de traitement ou si une nouvelle tentative est nécessaire.
Il existe également une gestion des quotas et des erreurs : par exemple, plusieurs comptes/slots peuvent être utilisés côté certains hébergeurs lorsqu’un quota de stockage ou une limitation est rencontrée.
Et pour les liens morts ?
C’est là qu’intervient la seconde partie du système.
Les posts déjà traités sont régulièrement repris par une seconde phase de contrôle. Le script vérifie l’état des différents miroirs disponibles et identifie ceux qui ne sont plus accessibles.
Pour 1fichier, le contrôle passe directement par son API. Un fichier supprimé ou retournant certains codes d’erreur est considéré comme indisponible. Le système peut alors rechercher une source encore valide parmi les miroirs existants et lancer automatiquement une nouvelle opération de remote upload vers 1fichier.
Par exemple, lorsqu’un miroir Up-4ever est encore disponible, son direct_link peut être utilisé comme source pour reconstruire le fichier sur 1fichier. Si cette possibilité n’est pas disponible, le système dispose de différents chemins de secours, notamment via MixLoads ou TorBox.
Le but n’est donc pas simplement de remplacer un lien mort, mais de reconstruire progressivement une chaîne de miroirs à partir des sources encore disponibles.
Une fois les nouveaux liens obtenus, le script modifie directement le contenu du post en base de données afin d’ajouter, remplacer ou actualiser les miroirs correspondants.
Une vraie machine à états
L’autre particularité du projet est que je ne voulais pas faire un énorme script qui lance tout en une seule fois.
Chaque opération possède son propre état : récupération de la source, upload distant, attente, vérification, nouvelle tentative, génération des miroirs, puis mise à jour du post.
Le système peut donc reprendre un traitement là où il s’était arrêté au prochain passage du CRON.
J’ai également mis en place plusieurs slots d’exécution parallèles avec des verrous afin que plusieurs jobs puissent être traités simultanément sans qu’ils se marchent dessus.
L’ensemble est piloté par MySQL, avec un historique des jobs, des erreurs, des tentatives et des dates de reprise.
L’objectif
L’idée derrière Immorta Link est finalement assez simple :
ne plus considérer un lien comme un élément isolé, mais comme une ressource qui peut être reconstruite à partir d’autres miroirs encore disponibles.
Cela permet de rendre le catalogue beaucoup plus résilient face aux suppressions, aux quotas, aux erreurs temporaires ou aux indisponibilités d’un hébergeur.
Le système n’est évidemment pas infaillible : s’il n’existe plus aucune source exploitable, il ne peut pas recréer un fichier à partir de rien. En revanche, tant qu’au moins une copie reste accessible, il peut essayer de reconstruire automatiquement une partie de la chaîne.
Je trouvais intéressant de partager cette approche de développement, notamment la partie machine à états, gestion des traitements asynchrones, reprise sur erreur, rotation des sources et synchronisation avec une base SQL.
Si certains ont déjà développé des systèmes similaires de traitement asynchrone ou de maintenance automatique de ressources, je serais curieux d’avoir vos retours sur l’architecture et les méthodes utilisées.
Pour ceux intéréssé par mon catalogue, n’hésitez pas, car pas de lien possible ici.
