Édit du 09 juillet 2011 à 18:13 : ayant fait de nombreuses corrections depuis que j'ai ouvert ce sujet, je prie ce qui m'ont lu depuis le début de ne pas m'en tenir rigueur.
Merci

Bonjour à tous,

Après une longue hésitation je me suis décidé à vous présenter un petit utilitaire StealthNET que j'ai fait il y a 2 ans, utilitaire sans prétention mais d'une efficacité redoutable dans la prévention des pertes de téléchargements inopinées et toujours désagréables. C'est sa fonction principale.

L'EXE ne pèse que 96,7 ko

Il est écrit en PowerBasic pour Dos v3.5 (1997), donc avec 25 lignes et 80 colonnes. Pas de souris (bien que possible mais au combien inutile ici). Il est bien sûr compatible avec les noms longs de Win95 et au-dessus grâce à une petite astuce dans la programmation. Il fonctionne donc sur mes Windows 98se et XP et probablement sous Vista et Seven. Il peut lancer 2 StealthNet différents si besoin est depuis l'intérieur du programme.

Ce qu'il ne fait pas
1. Il n'agit absolument pas sur la vitesse de téléchargement des sources. Ce n'est pas un "mod", vous savez, ces saloperies qui sont peut-être responsables de la fin [presque] probable du développement de StealthNet ! Merci les Français + les Darknode et autres DeathBone allemands ! Vous n'avez pas été les premiers à tirer mais vos boulets ont été les plus gros et ont fait le plus de dégâts sur la motivation des développeurs.

2. Il ne fait pas encore le café ! Dommage mais je n'ai pas trouvé la solution.

Ce qu'il fait et bien
1. Il gère les fichiers sources et les fichiers temp de 2 StealtNET en même temps en déplaçant informations et fichiers temp de l'un à l'autre permettant ainsi de mettre en attente de jours meilleurs des téléchargements dont les sources sont "parties en vacances".

2. Il interdit le lancement d'une 2ème occurrence de StealthNET. Important ici car il procède à toute une série de vérification/modification avant le lancement de StealthNET, ce qui pourrait être néfaste pour le SN actif (downloads.xml et user.config par exemple)

3. Il intercepte toutes pertes de fichiers en cours de téléchargement à la suite d'un crash système ou de Windows en interdisant le lancement de StealthNET si le "downloads.xml" a été détruit et/ou en récupérant les informations dans le .BAK ou .BAK.BAK. En 2 ans à la semaine près je n'ai plus jamais perdu un seul téléchargement.

4. Il gère le fichier "user.config" selon le bon vouloir de l'utilisateur rendant inutile tout nouveau paramétrage dans une mise à jour ou une nouvelle version, ou encore dans le courant de la session. Chrono en main, je n'ai besoin que de 18s pour passer à une nouvelle version sans perdre le moindre téléchargement ni devoir retaper le moindre paramètre ! Bien entendu, tout EXE d'installation de SN est interdit de séjour sur mon ordinateur. Si ce "user.config" a disparu (cela peut arriver après une restauration système), il est recréé à partir du "StealthNet.exe.config" de la version SN en cours et des paramètres personnels connus de mon programme.

Il permet de ce fait d'utiliser à des fins d'analyse une version (très) ancienne de StealtNET sans craindre une incompatibilité dans la lecture du user.config. Comme par exemple la version RShare 0.7.1.4 dite "Chamäleon" de janvier 2007 (disons que j'ai du bricoler un peu, "Regensburger" de l'époque étant entre temps devenu "The_StealthNet_Team")

5. Dans ce même "user.config" il efface l'historique ô combien agaçant de toutes les recherches effectuées dans les sessions précédentes. Je n'ai d'ailleurs jamais compris les motivations qui ont poussé les développeurs à implanter cette bizarrerie dans SN.

6. Il signale toutes anomalies dans le répertoire des fichiers temporaires.

7. Il signale tout téléchargement en double entre les 2 stealthNET

8. Il peut théoriquement reconstituer intégralement le contenu du sectorsmap d'un fichier temporaire (et de son état d'avancement ) dont on aurait perdu toute information. Par exemple un fichier temp orphelin dont on ne sait plus d'où il vient.

9. Plus quelques autres petites fonctionnalités auxquelles je ne pense pas en ce moment

Image 1 C'est l'écran principal avec les 2 listes en cours de téléchargement, à gauche celle gérée par SN.1, à droite celle gérée par SN.2. Ces listes peuvent être triées par noms, par dernière fois reçu, par pourcentage de réception et par vus complets. Vu le nombre de fichiers possibles sur cet écran (20), ces tris ne sont donc pas d'un très grand intérêt. Le tri par défaut est le pourcentage d'achèvement des fichiers tel que StealthNET l'affiche lui-même.

1. F1 et F2 permettent de lancer le StealthNET N°1 ou N°2

2. F3 à F6 permettent de trier les listes d'affichage

Concernant la colonne "pourcentages", les valeurs sont calculées exactement comme le fait StealthNET en analysant le contenu du sectorsmap, chaque lettre correspondant au taux de remplissage d'un bloc de 192 ko dans le fichier temporaire.
(Au sujet de cette Base64 utilisée par StealthNET dans le sectorsmap, voir à la fin de cette présentation)

3. F7 permet de supprimer un fichier à droite ou à gauche sans attendre que SN soit lancé.

4. F10 non matérialisé ici permet d'afficher et donc de modifier quelques paramètres de configuration actuels de SN avant son lancement. Utile car certains nécessiteraient de quitter et de relancer son client:
- Port
- Nombre de connexions
- Capacité et limite de connexion
- Capacité et limite d'émission
- Langage de l'interface
- Nombre de téléchargement simultanés

5. En tapant le SN d'origine (1 ou 2) et le numéro du fichier dans la liste, il est possible de déplacer un fichier d'un coté à l'autre, l'entrée dans le downloads.xml et le fichier temporaire associé étant permutés dans les répertoires de StealthNET 1 et 2 et Temp 1 et 2.

Image 2 Un fichier orphelin a été détecté.
Ici, un fichier temporaire de SN.2 (nom de 128 caractères en hexadécimal) n'ayant pas d'entrée dans les downloads.xml/bak/bak.bak a été trouvé.

En général, ce type de fichier ne doit pas être effacé sans autre forme de procès car il s'agit la plupart du temps d'un fichier terminé qui n'a pas pu être déplacé dans l'incoming. Pour vérifier, voici comment procéder:
1. au départ, garder le nom de 128 caractères
2. ajouter à la fin le type d'extension probable ou utiliser un éditeur héxadécimal pour lire l'entête du fichier: .DOC .MP3 .AVI, etc. Si ça marche on peut alors choisir le nom que l'on veut et la récupération est terminée.
3. si cela ne marche pas, on peut effacer le fichier

Théoriquement il est possible, et je l'ai déjà fait, de recréer une entrée dans le downloads.xml avec son sectorsmap en analysant le contenu du fichier sur le disque dur par blocs de 192 ko pour trouver les caractères ascii correspondant au taux de remplissage du fichier sur le disque, par exemple "A" si totalement vide ou "/" si totalement plein. Il serait alors possible de remettre ce fichier en téléchargement à partir de l'état d'avancement trouvé. Mais bon, si ce fichier a été corrompu à la suite d'un crash de windows ou de SN, c'est la corruption du fichier final assurée. Pour plus de détails, ce sera pour une autre fois, may be.

Image 3 Récupération en cours des 13 téléchargements de SN1 dont j'ai effacé volontairement le XML et le XML.BAK

C'est la partie la plus importante de cet exposé et la raison première de l'existence de ce programme

Tout d'abord lire le sujet Comment Stealthnet sauvegarde ses fichiers

Puisque SN_UTIL intercepte le lancement de StealthNET pour vérifier la conformité des 3 fichiers downloads.*, cette image 3 ne devrait apparaitre qu'à la suite d'un crash important ayant sérieusement affecté les fichiers principaux de SN.

Dans le cas présent, seul le .BAK.BAK est encore opérationnel et mon programme s'en servira pour récupérer les liaisons nécessaires avec les 13 fichiers temporaires. Les téléchargements reprendront dans l'état où ils étaient environ 10 minutes avant l'incident sans risque de perte car ce sont les informations des sectorsmaps qui décident de ce qui doit encore être téléchargé et non les fichiers temp eux-mêmes.

On peut donc accepter sans crainte la récupération qui se fera en une fraction de seconde.

Image 4 Déplacement du 4ème téléchargement de SN2 vers SN1
Image 5 7 téléchargements anciens ont été déplacés de SN2 vers SN1 (à comparer avec Image 1)

C'est à mon avis le deuxième volet le plus intéressant du programme: déplacer les fichiers d'un répertoire StealthNET à l'autre. Mettre en attente en SN.2 des téléchargements qui se trainent sur SN.1 mais qu'on ne veut pas effacer, quitte à lancer SN.2 de temps en temps pour voir si les sources sont revenues, ou encore re-déplacer de SN.2 vers SN.1 un ou plusieurs fichiers au gré de ses besoins.

L'image 4 montre le mécanisme du déplacement du fichier 4 de SN.2, l'image 5 le résultat du déplacement de 7 fichiers de SN.2 vers SN.1

Image 6 Un même téléchargement a été trouvé sur les 2 SN. Effacement ici du moins avancé (76.9%)
Ce problème peut facilement survenir puisque SN_UTIL peut gèrer et lancer 2 StealthNET avec des contenus différents. Bien entendu, je n'ai pas besoin de préciser que ces 2 SN ne sont jamais lancés simultanément !

A ce propos, mon analyse du remplissage du sectorsmap du fichier est exacte à 32 ko près tout comme celle de StealthNet qui ne peut pas faire mieux (base64).

Voilà, la présentation de mon programme est en principe terminé, sauf correction toujours possible de ma part.

Bonnes vacances à vous tous.

Jean-Roger


Au sujet de cette Base64 utilisée par StealthNET dans le sectorsmap
Base64 sur Wiki
Ci-dessous la liste des 23 caractères pouvant se trouver dans le sectorsmap de StealthNET avec leurs bits et "poids" spécifiques.

Chaque octet du sectorsmap correspond à une zone de 192 ko sur le disque dur. Cette zone peut donc contenir 0 à 192 ko de données. Le taux de remplissage de cette zone se traduit sur l'octet du sectorsmap par un caractère en base64 particulier selon les bits qui sont mis à 1, donc occupés. Seulement 6 bits sur les 8 existants sont utilisés, soit les bits 0 à 5. 1 bit mis à 1 pèse 32 ko, les 6 pèseront donc 192 ko.

Il est bon de savoir que SN ne transmet au maximum que des blocs de 32 ko de données cryptées. Chaque bloc ira donc se placer dans une des 6 zones du bloc de 192 ko prévues pour cela, et dans le sectorsmap, le bit concerné passera de zéro à 1 et le caractère base64 sera modifié.

Le tableau qui suit ne sert qu'au calcul du taux de remplissage du fichier et non de sa restauration

A = 00000000      0 ko / 192 reçus : cette zone a besoin de toutes ses données

B = 00000001     32 ko

D = 00000011     64 ko

E = 00000100     32 ko

F = 00000101     64 ko

H = 00000111     96 ko

M = 00001100     64 ko

N = 00001101     96 ko

P = 00001111    128 ko

Q = 00010000     32 ko

R = 00010001     64 ko

T = 00010011     96 ko

X = 00010111    128 ko

c = 00011100     96 ko

d = 00011101    128 ko

f = 00011111    160 ko

w = 00110000     64 ko

x = 00110001     96 ko

z = 00110011    128 ko

3 = 00110111    160 ko

8 = 00111100    128 ko

9 = 00111101    160 ko

/ = 00111111    192 ko / 192 reçus : cette zone n'a plus besoin de rien

Il faut y ajouter 2 caractères neutres, le + et le =, utilisés dans le modulo de la taille du fichier en octets divisés par 196608. 196608 = 6 bits mis à 1 ou "/" ou 6 x 32768
(32768 octets = 32 ko)

Ce modulo est très difficile à appréhender et m'a posé pas mal de soucis dans le calcul du pourcentage. A titre d'exemple, voici 3 modulos de fin de fichier. On comprend bien pourquoi nous avons une incertitude de taille pouvant aller jusqu'à 32 ko

/g==  fin de fichier de 00000 à 32767 octets (00 ko à 32 ko -1 octet).



/A==  fin de fichier de 32768 à 65565 octets (32 ko à 64 ko -1 octet)



+A==  fin de fichier de 65566 à 98303 octets (64 ko à 96 ko -1 octet)

Au total : 25 caractères seulement sur les 65 de la base64. Insuffisant donc pour tout affichage de taille reçue plus précise.

Qu'est-ce que la "mise à zéro"
Je profite de cette occasion pour expliquer la signification de la "mise à zéro" dans ma traduction en français quand on ajoute un nouveau fichier. Je sais que la question a été posée sur certains forums.

Dans les versions anglaise et allemande nous avons:
-" Zero filling" (remplissage de zéros, sorte de formatage de bas-niveau du fichier)
- "Datei füllen" (remplissage du fichier)

Quand SN prend en charge un nouveau fichier de 100 Mo par exemple, il réserve immédiatement sur le disque dur une zone de même capacité. Mais comme cette zone contient probablement déjà des données anciennes, il procède à un "formatage logique" de cette zone qu'il remplit de caractères dit "NUL" (ascii "0" ou hexa "00"). Lu à l'aide d'un éditeur hexadécimal, le fichier ne contient que des "00" "00", ...

S'il s'agissait du chiffre "0", nous aurions des "48" "48", ..., et dans ce cas-là, le fichier serait déjà ... complet !

Quand chaque bloc de 192 ko a été "formaté", l'octet correspondant du sectorsmap reçoit le caractère "A". A la fin de la "mise à zéro", tout le fichier ne contient que des "00" et le sectorsmap que des "A". Si j'avais traduit "remplissage de A", vous pouvez imaginer la suite.

Sur le sectorsmap du fichier,
- un "A" veut dire : zone de 192 ko vide qui doit recevoir 6 blocs de 32 ko de données
- un "/" veut dire : zone de 192 ko pleine qui n'a plus besoin de rien
- sinon on est dans une zone de 192 ko à laquelle il manque certains blocs de 32 ko de données.