D-LAN

h1. TODO

* -Traiter tous les évènements du filesystem-

* -Gérer la priorité des demandes 'GetHashes' et plus généralement l'interruption du hashage non-explicite en cours-

* Penser à vérifer/filtrer tous les paths qui entrent

* -Renommer Tests en TestsLogManager et faire de même pour les autres tests. Mettre les tests dans le namespace du composant associé.-

* -Implémenter FileManager::GetEntriesResult-

* -Implémenter FileManager::getHashes et trouver une solution simple pour le callback-

* -Créer un maximum de tests les plus unitaires possibles en commençant d'abord par les plus simples puis en compliquant avec des accès concurrents, simuler des downloads et uploads. Finir par un test qui fait n'importe quoi de manière aléatoire. Éventuellement tester la monté en charge.-

* Add parameter to FileManager::Builder::newFileManager(..) to tell where are located the file cache.

* Réaliser un diagramme des appels à partir des threads, essayer au maximum de simplifier tout le bordel (regrouper des mutex, par exemple). Attention aux accès concurrents depuis les downloaders/uploader/main loop/fileupdate durant un scan/restoring/hashing, etc...

* Attention au restoring pendant la suppression (ou l'accès) d'un sharedirectory!

* Attention à la class Common::Hash qui n'est pas thread safe

* -Modification of the 'GetHashes' message : The result ('GetHashesResult') can be fragmented to send a subset of hashes...-

* -Add a 'Settings' directory to the core containing classes to get and set settings like _nick_, _logPath_, etc...-

* Take care about all error during IO operations in FileManager

* Add a periodic rescan for unwatchable directory, for example mounted netword cannot be watched

* -Permettre de lancer plusieurs core (chercher un port libre, le port est donnée dans le IMAlive)-

h2. Notes

* Regarder du coté de http://flattr.com/ pour la rémuneration

* Regarder du coté de qTorrent pour voir comment sont packagé les dll de Qt : http://qbittorrent.sourceforge.net/

* How a user can choose a shared directory when the core is remote ? The choose dialog must show the remote file structure !? See here : http://doc.trolltech.com/4.5/qfiledialog.html#setProxyModel

* Stocker les hashes dans plusieurs fichiers, un par volume. Cela permet de gérer le cas où une periphérique est déconnecté puis reconnecté, dans ce cas on ne supprime pas le fichier de hash.

** Plus simple encore : un fichier par partage, les fichiers ne sont jamais supprimés.

* Serveur d'intégration, tâches quotidiennes (dans l'ordre) :

* Création d'un dossier d nommé avec la date courante

* Pull du repo d'integration depuis le repo de reference

* Génération de la doc (doxygen)

* Compilation de tous les composants (+ tests) en debug et en release -> rapport 'compilation.log' dans d

* Execution des tests de chaque composants -> rapport 'tests.log' dans d

* Réalisation de versions d'installation : debug + release -> rapport 'install.log' + les installs (.deb, install.exe) dans d

* Pouvoir afficher les rapports dans redmine ?

* Pouvoir changer de langue à la volé dans les options. La langue par défaut est définit à l'installation.

* Prendre en compte le 64 bits ? Idéalement il faudrait que l'installeur inclut les deux versions et choisisse à l'installation en fonction de la plateforme courante.

* Mettre à jour protobuf et l'utiliser comme dll (comportement par défaut à partir de la 2.3

* Faire attention au erreur d'allocation throwé par new, les catcher (std::bad_alloc). Est-ce que cette exception peut être lancé depuis Qt ? (par exemple lors de l'insertion d'un élément dans un tableau). Est-ce vraiment utile ?

* Les dossiers de destination (read write) sont choisit dans l'ordre lors de l'écriture. Il faut que l'utilisateur puisse choisir cet ordre.

* Voir ici pour une solution qui permette de savoir l'espace restant sur le disque : http://lists.trolltech.com/qt-interest/2004-11/thread00873-0.html

* Faire attention aux dossiers qui se trouvent dans un dossier partagés et qui sont des volumes montés

* Utilisation de splice pour les transferts ? : 

Linux : http://www.kernel.org/doc/man-pages/online/pages/man2/splice.2.html

Windows : http://msdn.microsoft.com/en-us/library/ms740565%28VS.85%29.aspx

Déroulement :

1) peerManager ~> uploadManager.newUpload(socket)

2) upload -> fileManager.getChunk(hash).sendChunkToSocket(offset, socket)

    * Pour protéger le cache de fichier un QReadWriteLock pourrait être pas mal :

    * Lors de la mise à jour un lock de type write est posé

    * Lors d'une recherche c'est un lock de type read qui est utilsé.

Cela peut permettre de faire plusieurs recherches simultanéments.

* Il faut prévoir de pouvoir modifier dynamiquement le nombre de 'chunk downloader' (via des settings)

* Les chunk downloader ne trouvant rien à downloader doivent attendre de manière PASSIVE!

* Réflechir à l'utilisation de Powershell pour le pilotage d'ordis à distance lors des tests.

* Utilisation d'un QMainWindow avec le log et la liste des peers comme panel.

* Eventuellement utiliser le mode MDI

* Il n'y a actuellement aucune manière de déplacer les downloads via le client graphique (voir le protocol core<->gui), compléter le protocole et beaucoup réflechir ;)

* Afficher un splash screen pour la version beta publique du type : "Attention, Ceci est une version BETA, à n'utiliser qu'à des fin de tests!

ute anomalie peut être reporté ici : <redmine>"

* Voir le numéro du thread dans l'entrée d'un log

* Logger toutes les prises de lock, les attentes, la création et la descruction des threads, etc..

* Les logs vont dans un dossier définit dans les settings ou dans un repertoire temporaire si pas spécifié

* Se poser la question sur l'utilisation de QObject comme parent pour la plus part des objets. (arbre d'objets avec désallocation automatique).

* Le LogManager propose une interface 'ILoggable' permettant de logger des objets.

* Concernant l'i18n :

* Choisir à l'installation, présélectionner en fonction de la langue du système

* La langue est stocké dans un fichier de paramètre (dossier utilisateur ou base de registre)

* Tous les fichiers de langue compilés sont installé

* Un fois installé, dans les paramètres du logiciel il est possible de switcher dynamiquement de langue.

* Utiliser des Exceptions pour signaler si un objet (partagé entre plusieurs threads) a été supprimé. Par exemple un Fichier (IFile) peut avoir été supprimé par IFileManager alors que IDownloadManager possède toujours une référence dessus. Dans ce cas le prochain appel à IFile par IDownloadManager va lever une exception, celle-ci est attrapée et l'objet est enlevé de la liste. Comme l'on utilise des smart pointers, le dernier à enlever le fichier de la liste va effectivement le désallouer.

* La vitesse de hashage d'un ensemble de fichiers DOIT être plus rapide que celle de DC++ (pas forcément moins économe en CPU). Utilisation de plusieurs threads si plusieurs disques durs.

* ça va être difficile car on utilise sha-1 qui demande plus d'effort à calculé que Tiger-Hash

* Un thread par partage ?

* Bien penser la sécurité notamment au niveau d'attaque par flood ou d'usurpation d'id, réaliser un ban d'IP si nécessaire.

crire ici toutes les possibilités d'attaque : http://dev.euphorik.ch/wiki/pmp/Security

* Créer un système d'envoie de rapport d'erreur automatique incluant le log et le message d'erreur ainsi qu'un maximum d'autres infos (hardware, software?). Post sur HTTP ?

tention aux données personnelles)

* Passer en revu les bugs de DC++ pour éviter de refaire les mêmes erreurs :) : https://bugs.launchpad.net/dcplusplus/+bugs

* Ainsi que les problèmes décrits dans la FAQ : https://answers.launchpad.net/dcplusplus/+faqs

* Mettre en place une team de développement 'Ek dev Team'

* Utiliser les notifications de Win7 (pour le Core). Voir si Qt fournit une abstraction.

* Utilisation de gitorious : http://gitorious.org/ conjointement avec redmine

* Recherche de phrases tel que "I have a dog", utilisation de guillemets comme pour google :

1) chercher le noeud correspond à chaque mots "i", "have", "a", "dog"

2) prendre le noeud ayant le moins d'élément

3) tester la phrase avec chaque élément du noeud

* Voir cette page pour des algos de recherche dans des chaines : http://en.wikipedia.org/wiki/String_searching_algorithm

* Voir cette page pour de l'allocation par block (pool) : http://www.flipcode.com/archives/Fast_Allocation_Pool.shtml

-> A été essayé sans grande différence sur le word index

* Pourquoi ne pas identifier un chunk via le hash du fichier entier + un numéro ??? Cela permettrai de diminumer la quantité de mémoire dédier à stocker les hashes des chunks

* Avantages d'avoir plusieurs hash par fichier :

* Un download peut démarrer sans identifer tout le fichier

* Lors de la demande des hashes ('GetHashes') d'un fichier qui n'est pas hashé, les hashes peuvent être envoyés graduellement.

* Réaliser des tests de mise en veille de l'ordinateur

* Chat - Rooms

** La liste des rooms est listés en dessous de la liste des peers. Un textbox suivit d'un bouton 'join' se trouve just au dessus, il permet d'entrer le nom d'une room et de la rejoindre, si la room existe déjà on la rejoint sinon elle est créé. Il est possible de sélectionner une room existante, son nom s'inscrit alors dans la text box. En double cliquant sur une room existante on la rejoint automatiquement.

** Les rooms sont listées par ordre alphabétique et le nombre de participant est indiqué

** Lorsque que l'utilisateur joint une room un nouvelle fenêtre lui étant dédié s'affiche. Cette fenêtre montre sur le coté les personnes présente dans la room.

** Lors de la création d'une room, un hash généré aléatoirement lui est associé. La room est alors mise dans les rooms connues et l'utilisateur est définit comme faisant partie de la room.

** Les rooms dans lesquels on se trouve sont envoyées périodiquement via le message 'IMAlive'.

** Lorsqu'une room est vide, plus personne ne la liste dans le message 'IMAlive', elle disparait alors naturellement.

** Lorsqu'un message est envoyé dans une room, un datagrame UDP est envoyé à chaque personne de la room

* Chat - Private Rooms

** Les private rooms ne sont joignable que sur invitation

** Elles ne sont pas envoyé dans le message 'IMAlive'.

** L'envoie d'un message se fait de la même manière qu'une roome publique

** Pour inviter une personne on lui envoie simplement le nom de la room, son id et les participants, il peut décliner

** S'il accepte il le s'annonce auprès de tous les participants

** Une personne peut quitter une room, il le signale aux participants.

*** Une private room peut-être transformé en public room mais pas l'inverse

* Chat - privé entre deux personnes

** Une personne peut initier un dialogue privé avec une autre personne de la liste via le menu contextuel

** Dans ce cas une private room est créé entre les deux personnes

** D'autres personne peuvent être inviter à joindre la discussion

* Est-ce que Common::Hash doit être "thread-safe" ? (macro à activer)

* En même temps que la première release, publier une documentation sur le protocole utilisé dans redmine.

* Packaging

* Slogan : "For Great Justice!"

* Logo : un vaisseau spatial (remake du vaisseau dans Zero wings) suivit du texte AYBABTU écrit de manière futuristique (et penché^^)

* (mieux) Ou une tentacule stylisé en référence aux monstres du jeu. La tentacule pourrait encercler un fichier en rapport aux 'byte'

* Couleur : noir, rouge et bleu (voir le site 'coming soon')

* Style oldschool

* Features :

* No configuration needed, just launch and download

* Very low ressource usage : you can play a game and download in the same time

* Le site web : ultra minimaliste (utilisé si possible http://snapframework.com/ ) comprenant :

** Page 'Home'

** Une mini description

** Un gros bouton download

** Un screenshot

** Page 'In depth'

** Une liste de fonctionnalité

** Description détaillée des processus (cas utilisateur)

** Plusieurs screenshots

** Page 'FAQ'

** Page 'Development'

** Un lien vers le forum de Redmine

** Un lien vers la room Jabber

** Un lien vers la page pour soumettre un nouveau bug/demande

* Faut-il mettre des news ? On peut utiliser celles dans Redmine, voir même directement les afficher sur la page principale

* Statistiques importantes à connaitres :

* Le nombre d'ip différente visitant chaque page par tranche d'heure

* Un compteur du nombre de download par tranche d'heure (par ip et le download doit être complet)

* Une moyenne établie par tranche d'heure sur le débit du download, permet de savoir s'il faut augmenter la bande passante

* Mettre en place un tracker torrent et encourager son utilisation

* Utiliser un site spécialisé dans le streaming de fichiers : http://put.io

* Pour la beta, permettre de la télécharger depuis le site web à l'aide d'un code à entrer.

* Poster plusieurs codes différents sur plusieurs forums différents

* Aller crescendo dans la distrubution des codes, d'abord aux particuliers puis sur les forums, marquer à chaque fois la date et l'heure de la diffusion

* Mémoriser chaque download : {date+time, ip, code}

* La page de la beta contient simplement une petite description

* Avertir que ce n'est qu'une beta, qu'elle peut contenir des erreurs...

* Faire attention aux attaques par brute force

* Problème subtile au sujet des dossiers partagé en sortie (read/write) :

* Deux dossiers partagés a et b

* un ensemble de dossiers/sous-dossiers sont téléchargés et vont dans a

* a n'a plus de place

* b est donc choisit comme destination, les dossiers/sous-dossiers sont alors recréé à double, il appartiendra à l'utilisateur de merger ces deux dossiers

* Dans un cas très dégénéré un ensemble de dossiers/sous-dossiers peuvent être éclaté sur n partage

* Solution actuelle : l'utilisateur se démerde ;)