D-LAN

h1. BORDEL

h2. Notes

* Utiliser D-LAN sur internet via un VPN comme http://www.freelan.org/ ... à creuser

* Pouvoir partager les fichiers de manière individuelle

** Lors de la sélection d'un emplacement custom, seul le fichier est partagé (et non plus tout le dossier)

* Idées concernant les statistiques

** Pour les graphiques afficher deux lignes (abscisse + ordonnée) partant du curseur (comme wolfram alpha)

** Utiliser des dégradés de bleu sur fond noir comme les traders qui se la pètent : http://optionalpha.com/wp-content/uploads/2011/05/Stock-Chart-Patterns.jpg

** Afficher le nombre de téléchargement à coté de chaque fichier (dossier?) lors du browsage

* Lien très intéressant sur les caches en lecture et écriture de libtorrent : http://www.rasterbar.com/products/libtorrent/features.html

** Également : http://en.wikipedia.org/wiki/Libtorrent_%28Rasterbar%29

* 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

* 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 ?

* Utiliser D-LAN pour la inviter des gens dans une game (un peu comme steam)

** A partir d'une sélection de peers ([IP]) pouvoir lancer une partie

** Proposer une API permettant de faire des plugins en JS

** Pouvoir joindre directement un peer (qui est un serveur de jeu), par exemple un serveur armagetron (qui lui même proposerai les fichiers nécessaires pour y jouer)

** Exemple d'API :

*** ArmaPlugin a

*** a.joinServer(serverIP) // Ici le plugin d'armagetron va lancer le jeu et lui dire de se connecter au serveur

** Trouver un moyen de voir qui joue à quoi et de différencier les serveurs

** [..]

* Pouvoir mettre un commentaire pour chaque shared directory, celui ci s'affiche alors sous la forme d'un tooltip lors du browsage

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

* Afficher les shared folder avec une couleur différente par volume

* 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 ?

* 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)

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

* 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 ? (Attention aux données personnelles)

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

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

## prendre le noeud ayant le moins d'élément

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

* 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. Sous la forme d'un pdf?

* 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

* Utiliser un site spécialisé dans le streaming de fichiers pour la distribution des releases : http://put.io

* 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 ;)

h2. Amélioration du chat 

* Tous est en UDP

* Ajouter un message de quittance pour tous les messages (y compris les messages multicast)

* 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é

*** Il est possible de "dérouler" (treeview) une room pour voir ses occupants

** 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 (correspond au nom de la room pour les rooms publique?) 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 (unicast) 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

* Chat - Lors du lancement permettre au GUI de récupérer les n derniers message (chat) :

** Un datagramme multicast est envoyé, "GET_NB_CHAT_MESS_KNOWN"

** Un datagramme unicast est retourné : "NB_CHAT_MESS_KNOWN" avec le nombre de message connu

** Une connexion TCP est ouverte  vers le peer avec un nombre de messages connu suffisant et les derniers messages lui sont demandé.

** Chat message doit être tagé avec un ID pour éviter d'insérer des messages à double